sql

좋은 질문입니다. 대답은 결정 론적보다 확률 적이며 작은 예를 사용하여 내 견해를 설명하려고 노력할 것입니다.

SQL 주입 (SQLi)을 피하기 위해 쿼리에서 매개 변수를 사용하거나 매개 변수와 함께 저장 프로 시저를 사용하도록 제안하는 많은 참조가 네트워크에 있습니다. 저장 프로 시저 (예 :)가 SQLi에 대한 마술 지팡이가 아님을 보여 드리겠습니다. 책임은 여전히 ​​프로그래머에게 있습니다.

‘Users’테이블에서 사용자 행을 가져 오는 다음 SQL Server 저장 프로 시저를 고려하십시오.

create procedure getUser
 @name varchar(20)
,@pass varchar(20)
as
declare @sql as nvarchar(512)
set @sql = 'select usrID, usrUName, usrFullName, usrRoleID '+
           'from Users '+
           'where usrUName = '''+@name+''' and usrPass = '''+@pass+''''
execute(@sql)

사용자 이름과 비밀번호를 매개 변수로 전달하여 결과를 얻을 수 있습니다. 암호가 자유 텍스트로되어 있다고 가정하면 (이 예제의 단순성을 위해) 일반적인 호출은 다음과 같습니다.

DECLARE @RC int
DECLARE @name varchar(20)
DECLARE @pass varchar(20)

EXECUTE @RC = [dbo].[getUser]
   @name = 'admin'
  ,@pass = '!@Th1siSTheP@ssw0rd!!'
GO

그러나 여기에는 프로그래머가 저장 프로 시저 내부에서 사용하는 잘못된 프로그래밍 기술이 있으므로 공격자가 다음을 실행할 수 있습니다.

DECLARE @RC int
DECLARE @name varchar(20)
DECLARE @pass varchar(20)

EXECUTE @RC = [TestDB].[dbo].[getUser]
   @name = 'admin'
  ,@pass = 'any'' OR 1=1 --'
GO

위의 매개 변수는 저장 프로 시저에 인수로 전달되며 마지막으로 실행될 SQL 명령은 다음과 같습니다.

select usrID, usrUName, usrFullName, usrRoleID
from Users
where usrUName = 'admin' and usrPass = 'any' OR 1=1 --'

.. 사용자로부터 모든 행을 다시 가져옵니다.

여기서 문제는 “저장 프로 시저를 만들고 필드를 매개 변수로 검색하도록 전달”원칙을 따르더라도 SQLi가 여전히 수행된다는 것입니다. 이는 저장 프로 시저 내부에 잘못된 프로그래밍 방식을 복사하기 때문입니다. 문제에 대한 해결책은 다음과 같이 저장 프로 시저를 다시 작성하는 것입니다.

alter procedure getUser
 @name varchar(20)
,@pass varchar(20)
as
select usrID, usrUName, usrFullName, usrRoleID
from Users
where usrUName = @name and usrPass = @pass

제가 말하고자하는 것은 개발자가 먼저 SQLi 공격이 무엇인지, 어떻게 수행 할 수 있는지 배우고 그에 따라 코드를 보호해야한다는 것입니다. 맹목적으로 ‘모범 사례’를 따르는 것이 항상 더 안전한 방법은 아닙니다 … 그리고 아마도 이것이 우리가 많은 ‘모범 사례’를 가지고있는 이유입니다.