SQL Injection 방어 방법
실무 면접에서 해당 질문에 대해 받았는데 이미 이전 질문들에 머리가 하얗게 되어버린터..
대답못하면 그건 그냥 모르는거다고 인정하자.
그리고 소잃고 외양간 고치는 심정으로 정리를 해보자..
1. Prepared Statement의 사용개발자가 먼저 모든 SQL코드를 정의한 다음 나중에 각 매개 변수를 조회에 전달하도록 한다. 이 코드 스타일을 사용하여 데이터베이스는 어떤 사용자 입력이 제공되는지에 관계 없이 코드 및 데이터를 구별할 수 있다.
구문을 다시 붙여 공격자가 공격자가 SQL명령을 삽입한 경우에도 쿼리의 의도를 변경하지 못하도록 할 수 있다. 공격자가 'Tom'또는'1'의 사용자 ID를 입력하는 경우, 매개 변수화된 쿼리는 취약하지 않고 대신에 'Tom1'과 일치하는 전체 사용자 이름을 찾는다.
2. Stored ProcedureStored Prodecure가 항상 SQL주입으로부터 안전한 것은 아니다. 단, 표준 Sored Procedure 프로그래밍 구조는 안전하게 구현되었을 때 Prepared Statement 쿼리를 사용하는 것과 같은 효과를 가지고 있다. 이들은 개발자가 표준을 벗어난 작업을 수행하지 않는 한
자동으로 매개 변수가 매개 변수화된 SQL문만 작성하도록 개발자가 요구한다.Prepared Statement와 Sored Procedure의 차이점은 저장된 절차에 대한 SQL코드가 정의되어 데이터베이스 자체에 저장된 다음 응용 프로그램에서 호출된다는 점이다.
3. White List사용자 입력을 날짜, 숫자, boolean, 열거된 유형 등과 같은 문자열이 아닌 형태로 변환한 후 쿼리에 추가할 값을 선택하는 데 사용할 수 있다.
4. Escaping Input이 기법은 위의 어느 것도 실현 가능하지 않을 때 마지막 수단으로만 사용해야 한다. 입력 유효성 검사는 다른 방어에 비해 약하기 때문에 아마도 더 나은 선택일 것이고 우리는 이 방법이 모든 상황에서 모든 SQL주입을 막을 것이라고 보장할 수 없다. 이 기술은 사용자 입력을 쿼리에 올리기 전에 회피하기 위한 것이다.
(상세한 내용은 계속 추가하기로...)
Ref.] SQL Injection Prevention Cheat Sheet :
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_SheetSQL Injection 방어 방법 :
http://dal4segno.github.io/web-security/sql-injection/
