Protection contre l'injection SQL : les limites de mysql_real_escape_string()
Bien que mysql_real_escape_string() soit couramment utilisé pour empêcher l'injection SQL, il a été a affirmé qu'il pouvait être contourné avec des codages de caractères asiatiques spécifiques sur les sites Web qui n'utilisent pas de déclarations préparées.
Le problème du contournement
Selon Justin Shattuck, le contournement est possible en utilisant des caractères des encodages de caractères Big5 ou GBK. Ces encodages permettent aux barres obliques inverses d'être représentées sous forme d'octets d'ordre secondaire ou supérieur, ce qui peut confondre mysql_real_escape_string() et ne pas les échapper correctement.
Explication de Stefan Esser
Déclare Stefan Esser que la vulnérabilité est due au fait que mysql_real_escape_string() n'est pas au courant des modifications apportées via SET NAMES, ce qui peut changer l'encodage. Lorsqu'un codage multi-octets est utilisé, les barres obliques inverses peuvent être représentées sous forme de plusieurs octets, contournant potentiellement le processus d'échappement.
UTF-8 est-il sûr ?
Esser note que UTF-8 est une exception à ce problème, car il gère correctement les barres obliques inverses dans n'importe quelle position d'octet. Cependant, il recommande d'utiliser mysql_set_charset pour modifier l'encodage, car il s'agit d'une option plus sûre et plus récente.
Recommandations
Pour se protéger pleinement contre l'injection SQL, il est recommandé d'utiliser des fichiers préparés déclarations, qui ne sont pas sensibles à ce problème de contournement. Si les instructions préparées ne sont pas une option, vous devez considérer les éléments suivants :
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!