La classe mysqli en PHP protège-t-elle à 100% contre les injections SQL?

Question

J'ai vu beaucoup d'articles et de questions sur mysqli, et tous prétendent que cela protège contre les injections de SQL. Mais est-ce que c'est insensé, ou y a-t-il encore un moyen de le contourner? Je ne suis pas intéressé par le script intersite ni les attaques de phishing, mais uniquement par les injections SQL.

Ce que j’aurais dû dire au début, c’est que j’utilise des déclarations préparées. C'est ce que je voulais dire avec mysqli. Si j'utilise des instructions préparées sans aucune concaténation de chaîne, est-ce que c'est infaillible?

Answer 1

  

Mais est-ce infaillible, ou existe-t-il encore un moyen de le contourner?

Non, vous devez savoir ce que vous faites. Si vous utilisez des paramètres liés (fonctionnalité fournie par MySqli), vous êtes parfaitement à l'abri des attaques de type injection à partir de ce vecteur d'attaque . Cela n'empêche pas - le programmeur - d'intégrer directement des chaînes et de permettre ainsi des attaques par injection. Vous devez utiliser la fonctionnalité comme prévu.

Objet: modifier

  

Ce que j’aurais dû dire au début, c’est que j’utilise des déclarations préparées. C'est ce que je voulais dire avec mysqli. Si j'utilise des instructions préparées sans aucune concaténation de chaîne, est-ce que c'est infaillible?

Foolproof est toujours un mot si dangereux. Mais vous êtes à l'abri des attaques par injection pour les variables liées par des instructions préparées. En effet, les paramètres liés sont transmis séparément de la requête SQL. Avec le " traditionnel " Dans l’approche embed-string, le serveur de base de données doit analyser l’entrée et il y a beaucoup de cas marginaux dans cela (jeux de caractères, etc.). Lorsque les données et la requête sont envoyées séparément, aucune analyse réelle n'est en cours (au moins, aucune analyse des données variables).

Answer 2

Cela ne protège pas mieux des injections SQL que l'ancien module mysql, cela facilite simplement la tâche du développeur, qui peut désormais utiliser des instructions préparées au lieu d'appeler mysql_real_escape_string.