PHP est très souvent accompagné de MySQL. Or MySQL est mal configuré par défaut : tout est autorisé, même LOAD_FILE et INTO OUTFILE. De plus, échapper une chaîne d'octets (PHP ne gère pas Unicode) pour la passer à MySQL n'est pas toujours évidant car le charset du site web peut-être différent de celui de la base de données (il existe mysql_escape_string et mysql_real_escape_string ...) : http://www.abelcheung.org/advisory/20071210-wordpress-charse(...)
Je pense que n'importe quelle application utilisant des fonctions haut niveau pour gérer l'accès à la base de données (MySQL ou autre), peut se protéger des injections SQL.
Euh... on parlait de PHP ? Ah mince.
Je pense que le « problème » de PHP est qu'il est trop facile à utiliser et que n'importe quel quidam sans aucune notion de sécurité peut écrire et publier son site web. La majorité des développeurs préfèrent réécrire leur CMS troué que d'utiliser un CMS testé et éprouvé. http://blog.halon.org.uk/geek/debian/security/php_clippy.htm(...)
[^] # Re: Erf
Posté par Victor STINNER (site web personnel) . En réponse au journal Faille de sécurité critique dans Joomla 1.5. Évalué à 2.
http://www.abelcheung.org/advisory/20071210-wordpress-charse(...)
Pour info, d'autres failles liées à Unicode :
http://www.haypocalc.com/blog/index.php/2008/01/26/124-faill(...)
Je pense que n'importe quelle application utilisant des fonctions haut niveau pour gérer l'accès à la base de données (MySQL ou autre), peut se protéger des injections SQL.
Euh... on parlait de PHP ? Ah mince.
Je pense que le « problème » de PHP est qu'il est trop facile à utiliser et que n'importe quel quidam sans aucune notion de sécurité peut écrire et publier son site web. La majorité des développeurs préfèrent réécrire leur CMS troué que d'utiliser un CMS testé et éprouvé.
http://blog.halon.org.uk/geek/debian/security/php_clippy.htm(...)
Au moins avec le C, on n'a pas ces problèmes.