J'ai entendu dire que la solution la plus simple pour empêcher les attaques d'injection SQL est de coder tout le texte avant d'insérer dans la base de données. Ensuite, évidemment, décodez tout texte lors de l'extraction. L'idée étant que si le texte ne contient que des ampersands, des semi-couches et alphanumériques, vous ne pouvez rien faire de malveillant.
Pendant que je vois un certain nombre de cas où cela peut sembler fonctionner, je prévois les problèmes suivants dans l'utilisation de cette approche:
Y a-t-il quelque chose qui me manque?
Est-ce en fait une approche raisonnable du problème de la prévention des attaques d'injection SQL?
Y a-t-il des problèmes fondamentaux en essayant de prévenir les attaques d'injection de cette manière?
4 Réponses :
Vous devez empêcher l'injection SQL en utilisant des liaisons de paramètres (par exemple, ne concatéez jamais vos chaînes SQL avec entrée de l'utilisateur, mais utilisez des porteurs de places pour vos paramètres et laissez le cadre que vous utilisez à l'aide de l'évacuation droite). Le codage HTML, d'autre part, doit être utilisé pour empêcher les scripts inter-sites.
HTMLenCoding ne doit être utilisé que lors de l'affichage des données à l'utilisateur, de sorte que les valeurs d'origine sont stockées dans la DB.
Comment vous obtenez l'idée que le texte codé HTML ne contient que des ampersands, des demi-colons et alphanumériques après décodage?
Je peux vraiment encoder un "" "dans HTML - et c'est l'une des choses nécessaires pour avoir des problèmes (car il s'agit d'un délimiteur de chaîne dans SQL).
Ainsi, cela ne fonctionne que si vous mettez le texte codé HTML dans la base de données.
Ensuite, vous avez des problèmes avec une recherche de texte ... et une présentation de texte lisible à l'extérieur (comme dans le gestionnaire SQL). Je considérerais qu'une très mauvaise sitaution architecturée, comme vous n'avez pas résolu le problème, il suffit d'un vecteur d'attaque évident.
Les champs numériques sont toujours problématiques, à moins que votre manipulation HTML soit parfaite, ce que je ne supposerais pas, étant donné que la solution de contournement.
Utiliser des paramètres SQL;)
L'idée que le texte codé ne contient que des ampersands, des semi-couches et alphanumériques après l'encodage 'n'est pas la mienne, mais une revendication de la personne qui supporte cette méthode utilisée.
Le caractère unique qui permet à SQL Injection est le Delimer SQL String Delimer Ce caractère est représenté de la même manière dans SQL et en HTML. Donc, un encode HTML n'affecte pas du tout des attaques d'injection SQL. ', également appelé hex 27 ou décimal 39.
absolument pas.
Les injections SQL doivent être évitées par des requêtes paramétrées. Ou dans le pire des cas en échappant au paramètre SQL pour SQL, pas HTML. Chaque base de données a ses propres règles à ce sujet, l'API MySQL (et la plupart des cadres) par exemple fournit une fonction particulière pour cela. Les données elles-mêmes dans la base de données ne doivent pas être modifiées lorsqu'elles sont stockées.
L'échappatoire Les entités HTML empêchent des attaques XSS et d'autres attaques lors du retour du contenu Web aux navigateurs des clients.
Le moyen le plus simple d'éviter les attaques d'injection n'est pas de le faire! Des requêtes paramétrées ont été créées spécifiquement pour ce numéro et fournissent également un coup de pouce de performances pour les requêtes qui ne diffèrent que des valeurs. S'il vous plaît, pas, un ange meurt à chaque fois qu'un développeur ajoute des valeurs à SQL! wink
Pour le dossier, je ne fais pas cela et ne pense pas que ce soit une bonne idée. Je veux juste m'assurer que je comprends toutes les raisons pour lesquelles c'est mauvais!
Voir la grande information et les didacticiels sur Open Web App Open Security Project: owasp.org