Protection par injection SQL: l'erreur de citations uniques Escape

Dans le domaine du développement de logiciels, la prévention des attaques d'injection SQL est cruciale. Bien que les requêtes SQL paramétrées soient le meilleur moyen de nettoyer les entrées, certains développeurs utilisent toujours le mécanisme de défense qui échappe à des devis uniques et enferme les entrées utilisateur dans des devis uniques comme alternative.

Technique d'échappement défectueuse

La méthode consiste à remplacer toutes les citations uniques dans l'entrée de l'utilisateur par des citations simples doubles et à enfermer la chaîne entière en citations simples:

sSanitizedInput = "'" & Replace(sInput, "'", "''") & "'"

Le principe de cette technique est que toutes les citations uniques entrées par l'utilisateur sont effectivement neutralisées pour empêcher la terminaison de la chaîne. Par conséquent, tout autre caractère, comme un point-virgule ou un signe pour cent, fait partie de la chaîne et n'est pas exécuté en tant que commande.

vulnérabilité d'injection

Cependant, cette technique ne peut pas gérer les cas où l'entrée de l'utilisateur elle-même peut contenir des citations simples doubles. Dans ce cas, la chaîne se terminera et le reste de l'entrée peut être exécuté sous forme de commandes SQL.

Exemple d'entrée

Pour illustrer cela, considérez l'entrée de l'utilisateur suivant:

'SensitiveData' HAVING AMOUNT>2000 OR ''=''

Après l'exécution, le code deviendra:

SELECT * FROM ACCOUNT WHERE NAME='SensitiveData' HAVING AMOUNT>2000 OR ''=''

Cette entrée injecte avec succès la clause OR dans la requête SQL, contournant le nettoyage attendu.

Considérations supplémentaires

Il est important de noter qu'il existe d'autres vulnérabilités dans cette technique d'évasion, y compris:

• ne peut pas se défendre contre tous les types d'attaques d'injection SQL, telles que des attaques en utilisant des commentaires ou d'autres terminateurs de déclaration.
• Présentez les frais généraux de performances et de maintenance.
• rendre le code difficile à lire et à comprendre.

meilleures pratiques

ne comptez pas sur des techniques de nettoyage des entrées temporaires, suivez ces meilleures pratiques pour empêcher l'injection SQL:

• Utilisez des instructions paramétrées de la requête SQL ou JDBC.
• Seuls les valeurs et les formats d'entrée attendus (listes blanches) sont autorisées.
• Les listes noires ne sont utilisées que si vous êtes absolument nécessaire et après les autres mesures d'atténuation sont mises en œuvre.
• Évitez la concaténation dynamique SQL et String.
• Envisagez d'utiliser des procédures stockées avec des autorisations limitées de base de données.