Discussion :

[dukoid]

Tu as entièrement raison : il font cela parce c'est le Php qui permet d'avoir le plus facilement ce genre de problème.

Voilà c'est mieux, désolé.

n'importe quoi, les failles en sont pas liés aux langages : php, python ...... ça n'as vraiment mais VRAIMENT AUCUN RAPPORT.
la plupart des failles viennent du serveur, d'une mise à jour.... et donc c'est quoi le rapport avec le langage interprété ?

[dukoid]

voire n'ont aucune expérience, voire les deux

pourquoi tu m'insultes ? j'ai rien dit de mal

[skuatamad]

Le problème d'injection SQL avec PHP est lié au couple PHP/Mysql.
Historiquement la connexion se faisait avec la librairie mysql_query (qui date de Mysql 3 je crois) qui ne permet pas de faire de requête paramétrée...

Résultat des dizaines de milliers de sites ont été développés avec cette lib poubelle obsolète, et encore aujourd'hui je suis sûr qu'elle est utilisée sur des nouveaux projets, alors qu'elle est deprecated depuis quelques années.

Bien sûr, PHP est utilisé aussi par des amateurs ou des débutants, mais il y a tellement de tutos qui utilisent cette lib et qui montre le mauvais exemple... Et ces tutos ne sont pas écrits par des amateurs débutants, à commencer par ceux sur DVP...
http://sylvie-vauthier.developpez.co...ro-bdd#LVI-2-c

Mais bon c'est un tuto parmi des milliers, exemple pour faire de l'ajax (à l'époque), on améliore le tuto avec un peu de PHP/Mysql pour faire plus vrai et bam, on se fout des injections sql parce que ce n'est pas le propo du tuto :
http://siddh.developpez.com/articles/ajax/#LIV-A

Donc oui, les sites PHP ont probablement plus de failles de ce type, mais faut qu'en même avouer que les développeurs n'étaient pas aidés par les outils à leur disposition dans les années 2000, ainsi que par la grande quantité d'exemple ne les incitant pas à s'améliorer sur ce point...

Maintenant les sites/applis PHP/Mysql utilisent plutôt PDO ou un framework, les risques sont alors réduits si tant est que les développeurs y soit sensibilisés.

PS : Oui, il y a toujours eu mysql_real_escape_string, mais c'est pas aussi simple que ça :
http://stackoverflow.com/questions/5...-escape-string

[bretus]

Maintenant les sites/applis PHP/Mysql utilisent plutôt PDO ou un framework, les risques sont alors réduits si tant est que les développeurs y soit sensibilisés.

Le problème, c'est que les failles ne se limitent pas aux injections SQL... La faille SQL est une problématique que tu peux adresser globalement, mais tu en as des tas d'autres où tu dois mener une réflexion en fonction des données, du rôle de l'utilisateur, etc. Pire, certaines problématiques touchent à l'architecture de ton application : Comment s'assurer que le système ne croule pas sous les traitements en tâche de fond?

Tu auras beau prendre n'importe quel langage, n'importe quel framework; tant que le développeur n'est pas conscient des risques, il fera des conneries s'il n'a pas une certaine méfiance liée à la connaissance des principales failles de sécurité :
- "C'est quand même plus beaux si mes utilisateurs éditent les commentaires avec TinyMCE! Je vais stocker du HTML et l'afficher!"
- "Vous pouvez joindre n'importe quel fichier (même un .php), il ira dans le dossier http://monsite.org/public"
- "http://monsite.org/contact/145" (merci pour les mails des 144 précédents)
- "Cool, contrairement aux nuls en PHP, je peux lancer un thread!" (à 10 000, tu comprendras pourquoi tes collègues utilisent eux aussi des MQ)
...

Dans un monde idéal, il faudrait au minimum que les développeurs connaissent les principales vulnérabilités des applications et surtout qu'ils sachent se mettre en position d'attaquant pour tester leurs applications avant qu'un guignol s'en charge avec un script.

Mais bon, on en est pas là... On en est à sortir des outils qui vérifient entre autre que les développeurs ne commit pas leurs paramètres d'accès à GMAIL et AMAZON dans les dépôts GITHUB! Autant parler de développeurs plus ou moins conscients des risques sans oublier les décideurs : "Fais vite un prototype! Touche plus à rien ça marche!", "Tu as 3 mois d'expérience, tu peux travailler seul!", "Un audit de sécurité? Pas besoin!" (j'aurai changer de boite quand celle-ci fera les gros titres), "Stage : Développeur full-stack", etc.

Alors, comment dire : L'outil le plus exposé aux vulnérabilités est celui sur lequel on code en se moquant royalement des problématiques de sécurité. Accuser les outils ou le développeur, c'est souvent un peu facile. On fixe un budget de radin, on se retrouve avec un CMS intégrant des plugins dégueulasses (le tout sans mise à jour, because ça coûte et ça sert à rien puisque ça marche!). En conclure que le langage à la base des principaux CMS et le plus utilisés pour faire un formulaire à la va-vite est le problème, c'est prendre un sacré raccourci...

Ce qui serait intéressant à la rigueur, ce serait un scan dans des applications PHP/Symfony2, Java/Spring, Python/Django, Ruby/RoR avec la nature des failles découvertes. Là, on tomberait peut-être sur des informations intéressantes liés aux comportements par défaut des frameworks (exemple : defaultHtmlEscape pour les injections XSS)...

[imikado]

Exactement: la première erreur dans la sécurisation d'une application c'est de se croire à l'abri parceque ci ou ça..

Pareil pour l'histoire du SQLi lié à php/mysql, en oracle, sybase... on a également le choix entre pdo et des méthode "simples"

Mais le problème des SQLi est du coté du développeur qui ne pense pas toujours à utiliser ces fameuses prepare statement

Idem pour le Xss/Xsrf nullbyte ... ce n'est pas un problème technique mais applicatif

Idem pour le DDoS applicatif

J'avais écrit un article sur le sujet:
http://imikado.developpez.com/tutori...e-mkframework/

[oxedet]

@sergeobee
Chut... il y a probablement des accords business avec l'auteur de l'étude, mais il ne faut pas l'évoquer ici ;-) J'ai déjà été (mal) tagué parce que j'avais osé évoquer ce genre de chose dans une autre étude...

[heinquoi]

Il n'est pas fait mentions de l'emplacement de la faille. Cela fait pourtant la différence. Le code d'un site ou le code des lib utilisées par de nombreux sites. La différence est énorme. Un pirate préféra chercher des failles dans des lib puisqu'elle peuvent être utilisé sur plusieurs sites. Ce qui est beaucoup plus efficace pour le pirate. Et la ceux qui ont plus de 10 ans d’expériences se souviennent que justement Java et asp étaient les champions ... Ceci explique cela ...

[Luckyluke34]

Pour ceux que ça intéresse, il existe un papier très instructif de l'ANSSI (Agence nationale de la sécurité des systèmes d'information) sur la sécurité des langages : http://www.ssi.gouv.fr/agence/public...r-la-securite/

On est sur des concepts assez bas niveau, pas de benchmarks de technos mais des critères intéressants à prendre en compte pour le choix d'un langage de programmation (scoping, système de types, encodage, etc.) et des conseils pratiques pour les développeurs

• Ne pas utiliser des principes de programmation contre-intuitifs (toujours maitriser ce qu'on fait)
• Eliminer le non-déterminisme et rendre explicites les comportements indéfinis
• Eviter le laxisme, traquer les comportements indéfinis pour les logger
• Désactiver des optimisations qui pourraient fragiliser la sécurité
• Se prémunir des inputs confectionnés avec un but malveillant
• etc.

Every developer, for example, should be security-literate enough in order not to introduce vulnerabilities to start with.
[...]
developers should be able to have a broad vision encompassing most of the avenues of attacks. To this aim, we have the feeling that one has to learn the basics in several domains such as language semantics, compilation theory, operating system principles, computer architecture.

[Logan Mauzaize]

Puisqu'on en est à donner des liens utiles

• Open Web Application Security Project (OWASP)
• SEI Secure Coding
• US CERT (si vous êtes prêt à faire un minimum confiance au gouvernement américain ^^)
• Norse Attack Map (moins utile mais c'est très fun, limite hypnotique ^^)

J'avais aussi un lien avec la liste des failles/exploits par logiciels/bibliothèques et version. Mais je n'ai pas réussi à remettre la main dessus. Autrement on peut aussi les retrouver sur l'OWASP.

[gihaires24]

POur cette question je dirait qu'elle n'est pas assez bien poser.car parler de securite en langage serait encore parler du meilleur langage de programmation,Or il n'existe pas de language meilleurs que d'autres puisque tout depend de ce que l'on veut obtenir.Et parlant de securite,elle depend de l'utilisateur du langage en question .Donc pour moi aucun langage ne guaranti plus de securite que l'autre.

[RyzenOC]

Sans oublier qu'un langage peut être plus ou moins sécurisée en fonction d'un environnement spécifique (OS, architecture processeur...etc).

[redbullch]

Sans oublier qu'un langage peut être plus ou moins sécurisée en fonction d'un environnement spécifique (OS, architecture processeur...etc).

Très juste, comme par exemple l'ASLR qui rend difficile d'exploiter un buffer overflow, et ça même si le développeur a fait de la m*** .

[sarra02]

la sécurité est la chose la plus importante dans toute application ... Moi je travaille avec java

[vivid]

"Les langages les moins sécurisé je pense que c'est les langages bas niveau (C, C++ par exemple), car il plus facile pour un pirate de corrompre la mémoire."

mais bien sur... faut-il encore savoir ecrire en C. Moins d’intermédiaire mieux c'est.