`mysql_real_escape_string()`은 실제로 SQL 주입을 방지합니까?

SQL 주입 방지에 mysql_real_escape_string()이 충분합니까?

많은 사람들이 mysql_real_escape_string()을 사용하면 SQL 주입을 방지할 수 있다고 믿고 있지만 실제로는 우회 가능성.

결점

다음과 같은 특정 경우:

mysql_query('SET NAMES gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

서버의 예상 문자가 일치하지 않아 문제가 발생합니다. 설정과 클라이언트의 인식. 서버의 문자 세트를 수정하기 위해 'SET NAMES'를 사용함으로써, mysql_real_escape_string()은 ASCII처럼 ' 이스케이프할 수 있지만 서버는 이를 일반 텍스트로 예상합니다. 이로 인해 불일치가 발생하고 'free-hanging' 및 주입이 허용됩니다.

The Bad

PDO의 준비된 명령문에 대한 기본 에뮬레이션도 이러한 허점으로 이어질 수 있습니다. 에뮬레이션을 비활성화하는 것이 권장되지만 지원되지 않는 쿼리에 대해 에뮬레이션으로 대체하면 완전한 보호가 불가능할 수 있습니다.

The Ugly

MySQL 4.1.20 이전에는 버그로 인해 잘못된 멀티바이트 문자가 허용되었습니다. 올바른 클라이언트 문자 집합이 있어도 페이로드에서 단일 바이트로 이스케이프되는 것과 같습니다. 정보.

The Saving Grace

utf8mb4 또는 utf8과 같은 불침투성 문자 세트를 사용하거나 NO_BACKSLASH_ESCAPES SQL 모드를 활성화하면 이에 대한 보호를 제공합니다.

결론

mysql_real_escape_string()을 사용하는 것은 많은 상황에서 여전히 효과적이지만 잠재적인 극단적인 경우를 인식하는 것이 중요합니다. 열거된 필드 및 준비된 명령문과 같은 보안 기술을 적절한 문자 세트 및 모드 구성과 함께 사용하는 것은 포괄적인 SQL 주입 방지에 필수적입니다.

위 내용은 `mysql_real_escape_string()`은 실제로 SQL 주입을 방지합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!