Analyse : retour sur les 130 millions de cartes volées ou la sécurité des applications en question

Troisième observation : le terrain de bataille de la cyber-criminalité n’est plus principalement le réseau comme auparavant mais plutôt les applications. Un très grand nombre d’applications concernant des flux financiers ou d’autres données confidentielles sont maintenant accessibles de partout dans le monde sur Internet (ou bien au-travers des Intranets). Beaucoup comportent des vulnérabilités importantes et multiples, surtout lorsqu’elles sont anciennes.

Ce qui est le plus choquant dans cette dernière affaire est l’utilisation de l’Injection SQL, une technique qui est presque aussi vieille que le langage SQL. L’injection des commandes SQL – soit dans des champs utilisateurs soit dans la fenêtre URL – permet à celui qui attaque une application vulnérable de découvrir la structure des tables puis d’en extraire des données. Cette même technique était employée en 2005 dans l’attaque contre CardSystems, une attaque dont les coûts étaient tellement élevés que la société victime a manqué faire faillite.

Toutefois, la popularité de l’Injection SQL ne devrait pas nous faire oublier d’autres techniques comme, par exemple, l’Injection LDAP, les Attaques SOAP, l’Injection XPath, etc. En tout état de cause, si l’affaire Gonzales était assez sophistiquée sur le plan organisationnel, elle semble avoir été assez basique sur le plan technique. Il ne faut pas oublier non plus qu’avec le temps, les hackers peuvent trouver de nouvelles astuces, ce qui fait qu’une application jugée non vulnérable en 2008 peut le devenir en 2009.

Ceci nous amène à notre quatrième observation, à savoir, que la sécurisation des applications doit couvrir l’ensemble de leur cycle de vie, de la conception jusqu’à la production normale en passant par le codage et les différentes recettes. Trop souvent, les exigences de sécurité ne sont pas correctement prises en compte en amont, parce que les développeurs des applications ne sont pas familiers avec la sécurité et les experts en sécurité ne connaissent pas les applications. Dans la phase de conception par exemple, de nombreux aspects sont à traiter, notamment les validations obligatoires (pour bloquer des injections), l’encryption éventuelle des données, les fonctions DB à désactiver, l’interaction avec des applications existantes, etc.

Ensuite, le coding devrait respecter des standards qui reflètent au moins une vision des vulnérabilités connues. Préalablement à la recette en production, la revue du code – soit de manière manuelle soit par analyse automatisée – s’impose. Enfin, les applications à risque déjà en production devraient être contrôlées régulièrement. Bien entendu, l’importance des efforts consentis devrait être modulée en fonction des enjeux par une analyse des risques régulière.