>백엔드 개발 >PHP 튜토리얼 >mysql_real_escape_string()은 정말 안전한가요? 아시아 문자 인코딩의 잠재적인 함정.

mysql_real_escape_string()은 정말 안전한가요? 아시아 문자 인코딩의 잠재적인 함정.

DDD
DDD원래의
2024-10-26 15:02:02704검색

 Is mysql_real_escape_string() Really Safe? The Potential Pitfall with Asian Character Encodings.

SQL 주입 방지: mysql_real_escape_string()의 한계

mysql_real_escape_string()은 일반적으로 SQL 주입을 방지하는 데 사용되지만, 준비된 문을 사용하지 않는 웹사이트에서는 특정 아시아 문자 인코딩을 사용하여 우회할 수 있다고 주장했습니다.

우회 문제

Justin Shattuck에 따르면 우회는 다음과 같습니다. Big5 또는 GBK 문자 인코딩의 문자를 사용하여 가능합니다. 이러한 인코딩을 사용하면 백슬래시가 2차 또는 더 높은 순서의 바이트로 표시될 수 있으며, 이로 인해 mysql_real_escape_string()이 제대로 이스케이프되지 않도록 혼동될 수 있습니다.

Stefan Esser의 설명

Stefan Esser는 다음과 같이 말합니다. mysql_real_escape_string()이 인코딩을 전환할 수 있는 SET NAMES를 통해 이루어진 변경 사항을 인식하지 못하기 때문에 취약점이 발생합니다. 멀티바이트 인코딩을 사용하면 백슬래시가 여러 바이트로 표시되어 잠재적으로 이스케이프 프로세스를 우회할 수 있습니다.

UTF-8은 안전한가요?

Esser는 다음과 같이 말합니다. UTF-8은 모든 바이트 위치에서 백슬래시를 올바르게 처리하므로 이 문제에 대한 예외입니다. 그러나 그는 인코딩을 변경하려면 mysql_set_charset을 사용하는 것이 더 안전하고 최신 옵션이기 때문에 권장합니다.

권장 사항

SQL 주입을 완벽하게 방지하려면 prepare를 사용하는 것이 좋습니다. 이 우회 문제에 취약하지 않은 문입니다. 준비된 명령문이 옵션이 아닌 경우 다음을 고려해야 합니다.

  • mysql_real_escape_string()에서 SET NAMES 사용을 피하세요
  • 필요한 경우 mysql_set_charset을 사용하여 인코딩을 변경하세요
  • 이 우회에 취약하지 않으므로 UTF-8 인코딩을 사용하세요

위 내용은 mysql_real_escape_string()은 정말 안전한가요? 아시아 문자 인코딩의 잠재적인 함정.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.