dans le manuel PHP, il y a une note:
Remarque: si cette fonction n'est pas utilisée pour Les données d'échappement, la requête est vulnérable aux attaques d'injection SQL.
est-ce suffisant pour l'injection anti-SQL? Sinon, pourriez-vous donner un exemple et une bonne solution à l'injection anti-SQL?
3 Réponses :
Autant que je sache, c'est une solution solide pour éviter les attaques d'injection SQL.
Désolé j'ai oublié d'ajouter, que je pense que vous pouvez attaquer d'une URL.
Vous pouvez également, toujours, restreindre qui peut accéder à votre base de données et qui a les privilèges.
La meilleure solution est PDO .
Si vous utilisez le traditionnel mysql_query puis exécutez toutes vos données via mysql_real_escape_string () suffit.
Les requêtes paramétrées sont également disponibles dans les extensions PDO
mysql_real_escape_string est généralement suffisant pour éviter l'injection SQL. Cela dépend de cela d'être sans bug cependant, c'est-à-dire une petite chance inconnue, il est vulnérable (mais cela n'a pas encore manifesté dans le monde réel). Une meilleure alternative qui exclut complètement les injections SQL sur un niveau conceptuel est Préparation des déclarations . Les deux méthodes dépendent entièrement de vos appliquer correctement; I.e. Ni vous ne vous protégerons pas si vous vous en causez simplement de toute façon.
Juste pour clarifier: Il y a aussi une chance que AOP émule des requêtes préparées (pour mysql) et n'utilise pas les mysql natifs. Il n'y a pas de telles déclarations dans la documentation PHP (ou je ne peux en trouver un).
"PDO imitera pour les conducteurs qui ne les soutiennent pas" --- Cela ne suffit pas, car: a) installé (ancien) libmysql ne peut pas prendre en charge préparé; b) PDO ne peut toujours pas utiliser des déclarations préparées indigènes.
Voir [MySQL_Real_Escape_string () protège-t-il complètement contre l'injection SQL? ] ( Stackoverflow.com/Questtions/1220182/... ).
Certainement un duplicata de dessus