mysql_real_escape_string()이 SQL 주입으로부터 완전히 보호됩니까?

mysql_real_escape_string()이 SQL 주입으로부터 완전히 보호됩니까?

http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/ ?akst_action=share-this에는 특정 아시아 문자 인코딩으로 mysql_real_escape_string을 우회할 수 있다는 섹션이 있습니다.

BIG5 또는 GBK로 mysql_real_escape_string() 바이패스

"injection 문자열"
に関する追加情報：

위의 문자는 중국어 Big5 입니다.

이게 정말로 사실일까요?만약 그렇다면 준비된 성명서에 접근할 수 없다면 웹사이트를 어떻게 보호하시겠습니까?

스테판 에서에 따르면,mysql_real_escape_string() "[사용될 때] 안전하지 않습니다."

블로그에 올라온 그의 설명:

SET NAMES는 일반적으로 인코딩을 기본적인 것에서 응용프로그램이 필요로 하는 것으로 전환하는 데 사용됩니다.이것은 다음과 같은 방식으로 이루어집니다.mysql_real_escape_string이것에 대해서는 모릅니다.즉, 백슬래시를 허용하는 일부 멀티바이트 인코딩을 2번째 3번째 4번째 바이트로 전환하면 문제가 발생합니다.mysql_real_escape_string제대로 빠져나가지 못합니다UTF-8은 안전합니다.

인코딩을 변경하는 안전한 방법은mysql_set_charset, 하지만 그것은 새로운 PHP 버전에서만 가능합니다.

그는 UTF-8이 안전하다고 언급합니다.

이것은 2006년 5월에 고쳐졌다고 알려진 MySQL 서버 버그입니다.

참조:

• MySQL 버그 #8303: \을(를) 포함하는 멀티바이트 문자를 가진 문자열 리터럴의 어휘가 잘못 입력되었습니다.
• MySQL Bug #8317: 쿼리의 문자 집합 도입기가 연결 문자 집합을 재정의하지 못함
• MySQL Bug #8378: 클라이언트 문자 집합이 'gbk'인 문자열이 잘못 빠져나왔습니다.
• MySQL 5.1.11 변경 로그.

MySQL 4.1.20, 5.0.22, 5.1.11에서 버그가 수정되었다고 보고되었습니다.

4.1.x, 5.0.x 또는 5.1.x를 사용하는 경우 최소한 마이너 버전 번호로 업그레이드했는지 확인합니다.

이를 해결하기 위해 따옴표-탈출 문자로 백슬래시를 사용하지 않도록 설정하는 SQL 모드를 사용할 수도 있습니다.

SQL을 사용하여 문자 인코딩을 변경하는 경우에만 작동하지 않을 것이라고 확신합니다.

다른 사람들이 보여준 것처럼, 애매모호한 에지 케이스에서는 우회할 수 있습니다.그것이 탈출 로직을 우회하는 알려진 전략 중 하나이지만, 아직 발견되지 않은 또 다른 알려지지 않은 취약점이 있을 수 있습니다.

PHP에서 SQL 주입을 방지하는 간단하고 효과적인 방법은 준비된 문을 사용할 수 있는 경우와 그렇지 않은 경우 매우 엄격한 화이트리스트를 사용하는 것입니다.

PDO 드라이버가 에뮬레이트하지 않고 실제로 사용할 때 준비된 문은 애플리케이션 보안의 근본적인 문제를 해결하기 때문에 (적어도 SQL 주입과 관련해서는) 안전할 수 있습니다. 즉, 데이터에 대해 작동하는 명령어와 데이터를 분리합니다.이들은 별도의 패킷으로 전송되며, 매개 변수화된 값은 쿼리 문자열을 오염시킬 기회가 없습니다.

2015년입니다.더 이상 도망치지 말고 속닥거리세요.여전히 애플리케이션(및 비즈니스) 논리에 따라 입력 내용을 검증해야 하지만 준비된 설명문만 사용해야 합니다.

언급URL : https://stackoverflow.com/questions/1220182/does-mysql-real-escape-string-fully-protect-against-sql-injection