`mysql_real_escape_string()` est-il une défense fiable contre l'injection SQL dans tous les encodages de caractères ?

Mysql_real_escape_string() est-il un bouclier imprenable contre l'injection SQL ?

Une section sur justinshattuck.com suggère que mysql_real_escape_string() est faillible contre certains Encodages de caractères asiatiques. Plus précisément, il prétend que l'encodage contourne mysql_real_escape_string() en utilisant BIG5 ou GBK pour introduire clandestinement des caractères dangereux dans les requêtes.

Cette vulnérabilité est-elle réelle ?

Selon Stefan Esser, la réponse est un oui déconcertant. Il affirme que mysql_real_escape_string() échoue lorsque SET NAMES est utilisé. Cette méthode change l'encodage pour s'adapter aux besoins de l'application sans en informer mysql_real_escape_string(). Par conséquent, si un codage multi-octets autorise une barre oblique inverse comme deuxième, troisième ou quatrième octet, des problèmes s'ensuivent. Mysql_real_escape_string() reste inconscient de cette irrégularité et ne parvient pas à échapper correctement les caractères.

Protéger votre site Web

Esser suggère que UTF-8 reste un encodage sûr, mais UTF -8 n'est pas toujours une option. Malheureusement, mysql_set_charset, l'alternative la plus sûre, n'est disponible que dans les versions récentes de PHP.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!