Les injections SQL dans les applications Web, pourquoi n'avançons-nous pas ?

Sécurité des applications
Les injections SQL dans les applications Web, pourquoi n'avançons-nous pas ?

L'actualité nous rappelle actuellement que le vol de données continue d'être un risque courant dans les applications. Juste pour ceux qui n'ont pas suivi l'actualité, on trouve en vrac :

La chaîne de supermarchés Target (http://krebsonsecurity.com/2014/01/a-first-look-at-the-target-intrusion-malware/) aux USA qui s'est fait volé entre 30 Millions et 110 Millions de données CB via un "malware".

Les chaînes d'hôtel Hilton et Mariott (http://www.thewire.com/technology/2014/02/white-lodging-credit-card-hack/357650/) qui elles aussi se sont fait volé les CB, mais plus gravement que Target, car les pirates disposent de toutes les données CB (CVV2 inclus).

Orange qui lui a perdu les données de 800 000 clients (http://www.01net.com/editorial/613226/orange-pirate-800-000-clients-touches/#?xtor=RSS-28&_sm_au_=iVVq477MTsTKKQb3).

Et puis aussi Bell Canada via une injection SQL (http://www.databreaches.net/nullcrew-attack-on-bell-canada-was-sql-injection-and-bell-knew-weeks-ago-nullcrew/).

Si l'on s'intéresse particulièrement au dernier point sur Bell Canada, on peut se demander pourquoi en 2014 on trouve encore autant d'injections SQL et surtout pourquoi ce risque est encore le premier dans le Top10 OWASP 2013 (https://www.owasp.org/index.php/Top_10_2013-A1-Injection)...

L'un des premiers réflexes d'un développeur est de se tourner vers un moteur de recherche préféré (par exemple Google), et de taper une simple requête basique telle que celle-ci :

"exécuter un requête SQL en Java"

(https://www.google.fr/search?q=executer+une+requetes+SQL+en+java&oq=executer+une+requetes+SQL+en+java&aqs=chrome..69i57.5501j0j4&sourceid=chrome&espv=210&es_sm=119&ie=UTF-8#q=executer+une+requete+SQL+en+java&safe=off)

Attardons-nous sur les 5 premiers résultats :

  • 1er résultat : vulnérable à une injection SQL et aucune mention des problèmes de sécurité, ni aux requêtes paramétrées
  • 2ème résultat : évocation des requêtes préparées, mais aucune explication du pourquoi les utiliser
  • 3ème résultat : vulnérable à une injection SQL et aucune mention des problèmes de sécurité, ni aux requêtes paramétrées
  • 4ème résultat : vulnérable à une injection SQL et aucune mention des problèmes de sécurité, simple évocation des requêtes paramétrées
  • 5ème résultat : vulnérable à une injection SQL et des requêtes paramétrées, mais aucune évocation de la sécurité

S'il n'a pas de connexion Internet, le développeur va ouvrir quelques livres sur Java :

  • programmingLe livre "Apprenez à programmer en Java" sur le site du Zéro (ou en librairie) : injections SQL dans le chapitre 12, et évocation des requêtes paramétrées, uniquement pour des raisons de "performance",
  • Le livre "JDBC et Java : guide du programmeur de chez Oreilly" : premiers exemples vulnérables aux injections SQL,
  • Le livre "Database Programming with JDBC & Java, 2nd Edition" : premier chapitre, les exemples sont tous vulnérables aux injections SQL.

Et puis, on peut espérer que sinon, il a été formé précédemment dans son université :

Après une recherche simple de cours d'université (https://www.google.fr/search?q=executer+requete+SQL+en+java+universit%C3%A9&oq=executer+requete+SQL+en+java+universit%C3%A9&aqs=chrome..69i57.7159j0j4&sourceid=chrome&espv=210&es_sm=119&ie=UTF-8) on trouve que le problème n'est pas ou est mal traité dans l'apprentissage du langage Java.

Exemples :

Tout ceci nous amène à la conclusion suivante :

Le SANS suite à une longue étude en est venue à cette conclusion (http://www.scmagazineuk.com/app-security-severely-hampered-by-skills-shortage/article/332640?utm_content=buffera86a0&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer) : la sécurité applicative souffre d'une méconnaissance de la part des développeurs.

Nous ne pouvons que partager leur vision dûe aux différents éléments notés précédemment : l'auto-formation des développeurs, ainsi que les formations initiales ne sont pas adaptés. En effet, 4 exemples sur 5 sur les résultats de Google sont vulnérables, les premiers chapitres des livres sur Java et SQL ne présentent pas les bonnes "pratiques" de base. Et on constate aussi que dans les universités, la première présentation des liens Java vers SQL ne sont pas non plus dans les bonnes pratiques.

Au final, comment combattre les injections SQL :

  • Implémenter les bonnes pratiques de sécurité dans le développement
    • Valider les entrées utilisateur
    • Utiliser les requêtes paramètres
    • Mettre en place des mécanismes de défense en profondeur dans le code
    • Former les différents acteurs de la chaîne du développement, à la sécurité et faire des démonstrations sur le code "maison"
  • Surveiller vos logs et le réseau vis-à-vis des attaques
  • Mettre en place un bouclier virtuel
    • Firewall
    • Firewall de base de données
    • Web application firewall
  • Mettre en place un environnement de tests réguliers sur les applications Web
    • Automatisation via des scanners de tests d'injections
    • Analyse du code source via des outils automatisés
    • Tests d'intrusion manuel
  • Effectuer un durcissement de la base de données
    • Appliquer le principe du privilège sur l'accès à la base/aux tables
    • Ne pas utiliser des comptes à privilège de type administrateur pour les accès dans l'applicatif
    • Mettre en place les patches réguliers de la base de données

Quelques références sur les solutions :

OWASP's SQL Injection cheat sheet : https://owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

OWASP's Input Validation cheat sheet : https://owasp.org/index.php/Input_Validation_Cheat_Sheet

Sébastien Gioria, Consultant Sénior en Sécurité des Systèmes d'Informations, Advens