Produire du code sécurisé pour le web… une bonne blague ?

Le 12 janvier a vu la parution d’un document qui vaut le coup d’oeil et même un peu plus : « les 25 erreurs de programmation les plus dangereuses » qu’on ne trouve pour le moment qu’en VO.

On y trouve en particulier les 3 failles majeures d’un très grand nombre d’applications web :

– Vulnérabilité aux injections SQL

– Vulnérabilité aux attaques de type « Cross Site Request Forgery »

– Vulnérabilité au Cross Site Scripting (attaques XSS)

A l’occasion d’une petite discussion avec François Tonic (rédac chef du magazine Programmez) et quelques collègues sur ce sujet, plusieurs réflexions sur la place de la sécurité dans les projets web nous sont apparues d’une actualité criante :

– les développeurs sont, de manière générale, assez inconscients des problématiques de sécurité posées par leurs applications

– les chefs de projet ayant un profil insuffisamment technique (chose plus que courante sur les projets web…) sont au mieux incapables de contrôler le boulot des développeurs, au pire complètement ignorants de la problématique de la sécurité.

– les clients sont, eux aussi, insuffisamment sensibilisés à la question et tombent souvent des nues quand ils voient apparaître un budget « sécurité » conséquent dans une proposition commerciale

– trop souvent, la sécurité est vue comme une question annexe qui pourra être réglée après coup à l’aide d’un audit et de quelques patches… ce qui est en réalité un très mauvais calcul : la sécurité doit être une problématique quotidienne pour les développeurs, le contrôle a posteriori est moins efficace et plus coûteux

Pas convaincus ? Regardez donc ces quelques exemples :

Une belle attaque CSRF sur le site d’une banque permettant à un attaquant de faire des transferts sur des comptes qui ne lui appartiennent pas

Une petite injection SQL pour hacker un site d’un éditeur d’antivirus

Une faille XSS qui ouvre la voie à une belle opération de phishing sur un système de paiement sécurisé

Toujours pas convaincus ?