L'injection SQL est-elle un risque aujourd'hui?

Question

J'ai lu à propos des attaques par injection SQL et comment les éviter, même si je peux ne semblent jamais faire de "l'affreux" exemples de travail donnée, comme par exemple ce post http://stackoverflow.com/questions/332365/xkcd-sql-injection-please-explain

J'ai créé un fichier php et d'une table dans la base de données a une valeur transmise par le biais $_GET et essayé de supprimer la table en procédant bob'); drop table students; -- et ça ne fonctionne pas. PHP automatiquement échappe à l' \' et la requête comporte une erreur, pas de dégâts. Même problème lorsque j'essaie de reproduire login "attaques" comme AND WHERE 1=1 etc.

exemple de code:

<?php
$id = $_GET['id'];

$sql = "INSERT INTO Users (Username) VALUES ($id)";
echo $sql;
mysql_query($sql) or die(mysql_error());

Et je voudrais passer sql.php?id=1); delete from Users; --

Donc, ce n'est pas datée truc qui sert à appliquer dans les jours de PHP3 ou quelque chose, et aujourd'hui, même les novices sont protégés des choses comme les magic quotes?

Je suis en PHP5 sur Ubuntu.

Answer 1

Tout à fait le contraire. Magic quotes sont déconseillés en PHP5 et sera complètement supprimé dans PHP6, comme ils ont apporté plus de confusion pour le monde de la programmation qu'ils ont fait du bien. Vérifier si les magic quotes sont actifs, et d'échapper à toute SQL entrée scrupuleusement si nécessaire, est encore très, très important... Aucune raison de se sentir si mal, nous avons tous été là, et ma méconnaissance de l'ass a été sauvé par des magic quotes un nombre incalculable de fois :)

Le manuel PHP sur magic quotes explique tout: http://www.php.net/magic%5Fquotes

Answer 2

Non, cela reste très pertinent.

De même que XSS et CSRF. Ne sous-estimez jamais l’importance d’un filtrage adéquat des entrées.

Answer 3

Heh, vous êtes sauvé dans ce cas en ayant magic_quotes_gpc réglé sur "on".

Vous allez être foutu bientôt .

Answer 4

La plus grande usurpation d'identité dans l'histoire a été réalisée en 2007 par l'exploitation d'une vulnérabilité d'injection SQL: voir "des attaques par injection SQL conduit à Heartland, Hannaford violations" (ComputerWorld, 8/18/2009).

OWASP déclaré en 2007 que les attaques par injection (dont l'injection SQL est un exemple) continuent à être l'un des les logiciels les plus courants des problèmes de sécurité.

Vous pouvez également rechercher les dernières SQL injection de nouvelles et de trouver beaucoup de cas signalés chaque mois: http://news.softpedia.com/newsTag/SQL+injection

Cependant, l'exemple de la XKCD dessin animé n'est pas nécessairement le type le plus commun de l'exploit. Suppression d'une table par l'exécution d'une deuxième instruction SQL dans une requête ne serait probablement pas gain de l'attaquant beaucoup dans la façon de précieuses données, il serait tout simplement du vandalisme.

Aussi, certains interface de requête d'interdire le multi-requête par défaut de toute façon. La base de données de l'API client ne s'exécute que dans un seul état donné de la chaîne SQL, indépendamment des points-virgules. Cela va à l'encontre de l'exemple montré dans le dessin animé.

remarque: AOP de l' query() méthode est connue à l'appui de multi-requête par défaut. Donc, il est sensible à la XKCD-attaque de style.

Comme d'autres personnes l'ont souligné, le plus probable, le risque est qu'une injection SQL va modifier la logique des expressions SQL, et appliquer à votre requête de lignes supplémentaires en plus de ceux que vous avez prévu.

Par exemple:

$sql = "UPDATE Users SET PASSWORD = MD5('" . $_POST["password"] . "'||salt) " . 
       "WHERE user_id = " . $_POST["userid"];

Ce qui se passe quand j'ai envoyer une demande avec le paramètre userid ensemble de la chaîne de caractères 123 OR userid=456? Je voudrais réinitialiser mon mot de passe (code d'utilisateur 123) ainsi que le mot de passe du nom d'utilisateur 456. Même le hachage du mot de passe par utilisateur sel ne serait pas protéger contre cela. Maintenant je peux me connecter en compte.

Il y a beaucoup de façons d'injection SQL peut être commise.

Answer 5

Magic quotes ne prenez pas de codage de caractères en compte, et sont donc vulnérables aux attaques basées sur multi-octets caractères.

Pour ce qui est du risque aujourd'hui, les recherches Google à son tour de nombreux sites vulnérables. Une vulnérabilité d'Injection SQL a été signalé pour Bugzilla autour du 10 septembre. Donc, oui, les sites sont toujours à risque. Devraient-ils être? Les outils sont là pour empêcher l'injection, donc non.