Maison >développement back-end >tutoriel php >Addslashes() en PHP peut-il toujours conduire à des vulnérabilités d'injection SQL ?

Addslashes() en PHP peut-il toujours conduire à des vulnérabilités d'injection SQL ?

Linda Hamilton
Linda Hamiltonoriginal
2024-12-02 15:46:12852parcourir

Can addslashes() in PHP Still Lead to SQL Injection Vulnerabilities?

Exploits d'injection SQL via addlashes() en PHP

La fonction addlashes() de PHP est connue pour être moins sécurisée que mysql_real_escape en ce qui concerne empêchant les vulnérabilités d’injection SQL. Bien que addlashes() soit souvent critiqué pour ses limites, il est important de comprendre comment il peut conduire à des attaques réussies.

Exemple de scénario

Considérez le code suivant qui tente de nettoyer saisie utilisateur :

$input = addslashes($_GET['input']);
$query = "SELECT * FROM users WHERE username='$input'";

Le problème avec ce code est que addlashes() ne gère pas correctement les caractères multi-octets. Si un attaquant fournit un nom d'utilisateur contenant un caractère multi-octets se terminant par le caractère barre oblique inverse (), addlashes() insérera une barre oblique inverse au milieu de la séquence, brisant ainsi sa validité. Cela peut entraîner l'interprétation de la barre oblique inverse comme un caractère d'échappement dans la requête SQL au lieu d'échapper au guillemet simple suivant.

Un exemple d'entrée malveillante qui pourrait exploiter cette vulnérabilité est :

%E4%B8%80' OR 1=1 --

addslashes() convertirait cela en :

%E4%B8%80\' OR 1=1 --

La barre oblique inverse échappée () devient désormais une partie valide de la séquence multi-octets, permettant au attaquant pour exécuter des commandes SQL arbitraires (dans ce cas, pour contourner l'authentification).

Avertissement général

La vulnérabilité survient car addlashes() peut être amené à créer un caractère multi-octets plutôt que d'échapper un guillemet simple suivant. Cela se produit lorsque le codage de caractères utilisé inclut un caractère multi-octets valide se terminant par 0x5c (le code hexadécimal du caractère barre oblique inverse). Bien que UTF-8 ne remplisse pas cette condition, d'autres codages, tels que Latin1, le font. Par conséquent, il est crucial d'être conscient de cette vulnérabilité potentielle lors de l'utilisation de addlashes() pour la vérification des entrées et d'envisager d'utiliser des alternatives plus robustes comme mysql_real_escape.

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn