SQL Injection: Poor Validation

HTML, XML 및 다른 형식의 인코딩을 사용하여 신뢰할 수 없는 입력을 검증하면 공격자가 문의 의미를 변경하거나 임의의 SQL 명령을 실행할 수 있습니다.

mysql_real_escape_string() 같은 인코딩 함수를 사용하면 일부 SQL Injection 취약점이 방지되지만 전부 방지되지는 않습니다. 이러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 SQL Injection을 차단하는 것과 동일하며 공격자가 문의 의미를 수정하거나 임의의 SQL 명령을 실행하는 것이 가능할 수 있습니다. 동적으로 해석되는 코드의 지정된 섹션 내에서 입력이 표시되는 위치를 정적으로 확인하는 것이 항상 가능하지는 않으므로 Fortify Secure Coding Rulepacks는 해당 컨텍스트 내에서 검증을 통해 충분히 SQL Injection을 차단할 수 있는 경우에도 검증된 동적 SQL 데이터를 "SQL Injection: Poor Validation" 이슈로 표시할 수 있습니다.

SQL Injection 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.



2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.

예제 1: 다음 예제는 데이터베이스의 구성으로 인해 변경될 수 있는 mysqli_real_escape_string()의 동작을 보여줍니다. SQL 모드가 "NO_BACKSLASH_ESCAPES"로 설정된 경우 백슬래시 문자가 이스케이프 문자[5]가 아닌 일반 문자로 처리됩니다. mysqli_real_escape_string()은 이를 고려하므로 다음 쿼리는 SQL Injection에 취약해집니다. 데이터베이스 구성으로 인해 "가 더 이상 \"로 이스케이프 처리되지 않기 때문입니다.

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

공격자가 password 필드를 비워 두고 " OR 1=1;-- 을 userName으로 입력하면 따옴표가 이스케이프 처리되지 않고 다음과 같은 쿼리가 생성됩니다.

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

OR 1=1로 인해 where 절이 항상 true로 평가되고 하이픈 두 개로 인해 나머지 문이 주석으로 처리되므로 이 쿼리는 훨씬 더 단순한 쿼리와 논리적으로 동일해집니다.

  SELECT * FROM users;

SQL Injection 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값 목록(허용 목록)의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록 검사는 엄격한 입력값 검증 규칙을 이행하는 매우 효율적인 수단이 되기도 하지만, 매개 변수가 있는 SQL 문은 유지 관리가 쉽고 보다 강력한 보안을 제공할 수 있습니다. 대부분의 경우 거부 목록 구현은 SQL Injection 공격 방지의 효과를 떨어뜨리는 허점이 아주 많습니다. 예를 들어, 공격자는 다음과 같이 할 수 있습니다.

- 따옴표로 묶지 않은 필드를 노립니다.
- 이스케이프 처리된 메타 문자를 사용할 필요가 없는 방법을 찾습니다.
- 저장 프로시저(Stored procedure)를 사용하여 삽입된 메타 문자를 숨깁니다.

SQL 쿼리에 입력할 때 수동으로 문자를 이스케이프 처리하는 방법도 있지만 이것으로 SQL Injection 공격으로부터 응용 프로그램을 보호할 수는 없습니다.

SQL Injection 공격을 다루는 데 주로 제시되는 다른 솔루션은 저장 프로시저(Stored procedure)를 사용하는 것입니다. 저장 프로시저(Stored procedure)는 일부 유형의 SQL Injection 공격은 막을 수 있지만 다른 많은 유형은 막지 못합니다. 저장 프로시저(Stored procedure)는 일반적으로 매개 변수에 전달되는 SQL 문의 유형을 제한하여 SQL Injection 공격을 막습니다. 하지만 이 제약을 피할 수 있는 많은 방법이 있어 수많은 비정상적인 문을 저장 프로시저(Stored procedure)에 전달할 수 있습니다. 다시 말해, 저장 프로시저(Stored procedure)는 일부 익스플로이트는 막을 수 있지만 응용 프로그램을 SQL Injection 공격에 대해 안전하게 보호할 수는 없습니다.