Dans une étude réalisée par le Ponemon Institute pour le compte de DB Networks, 65 % des entreprises interrogées reconnaissent avoir subi une ou plusieurs attaques par injection de commandes SQL au cours des 12 derniers mois. De plus, en moyenne, l'incident a été découvert au bout de 140 jours, et il a fallu 68 jours pour résoudre le problème. « On sait que les entreprises doivent lutter contre les failles par injection SQL, et près de la moitié de celles qui ont répondu à notre enquête ont déclaré que le risque était très important pour leur entreprise. Mais l'étude examine la question de manière beaucoup plus approfondie », a commenté le Dr Larry Ponemon.

Ainsi, quand l'étude pose la question de la prévention des attaques par injections SQL, les mêmes entreprises répondent que les mesures prises pour se protéger sont insuffisantes : 52 % des entreprises interrogées reconnaissent qu'elles ne prennent aucune précaution, et qu'elles ne font par exemple aucun audit de code et ni aucun contrôle de validation. Pourtant, près de la moitié d'entre elles ont déclaré que les attaques par injection SQL représentent pour elles une menace importante. De plus, 42 % savent que l'injection SQL favorise les intrusions. Ce défaut de prévention peut s'expliquer en partie par le fait que seules 31 % des entreprises interrogées estiment que les équipes IT chargées de la sécurité des systèmes ont les compétences, les connaissances et l'expertise pour détecter une attaque par injection SQL.

595 entreprises interrogées pour cette étude

L'échantillon qui a servi de base à cette étude est toutefois réduit, seulement 595 entreprises sur 16 marchés verticaux. Mais, le problème posé par l'injection SQL est beaucoup plus large : en fait, il a été identifié depuis 1998. Une des raisons pour lesquelles l'Injection SQL existe c'est que, du côté des attaquants, cela donne de bons résultats. On trouve sur le web plusieurs outils qui permettent d'automatiser l'injection SQL, depuis l'analyse des hôtes vulnérables, jusqu'à l'extraction des données de la base de données, et la plupart des cybercriminels n'ont pas besoin d'autre chose pour voler des données.

Pour les entreprises, la question est un peu plus complexe. Les développeurs sont payés au code, mais la sécurité n'est pas encore une priorité. L'essentiel, c'est que le projet soit livré en temps voulu et qu'il respecte le budget. Depuis 1998, le développement de code a fait beaucoup de chemin, mais pas mal d'erreurs passent encore entre les mailles du filet. Et ce sont ces petites erreurs qui ouvrent la porte à de larges brèches. C'est pourquoi les évaluations de code et la surveillance continue des applications et des bases de données sont encouragées, voire carrément obligatoires.

Un problème à prendre au sérieux

Pourtant, régulièrement, les entreprises subissent des attaques par injection SQL, et leurs conséquences peuvent être coûteuses et embarrassantes (notamment vis-à-vis des clients). Évidemment, l'objectif de DB Networks pour prévenir contre les attaques par injection SQL n'est pas désintéressé, comme c'est le cas d'autres fournisseurs. Mais quelques précautions de bases suffisent souvent à résoudre les problèmes d'injection SQL les plus fondamentaux, comme ceux décrits par l'OWASP (The Open Web Application Security Project), une ONG mondiale qui travaille sur la sécurité des applications. Mais, quelle que soit la méthode choisie par une entreprise pour résoudre le problème de l'Injection SQL, l'essentiel est de s'en préoccuper. Ce n'est jamais facile, mais compte tenu de la valeur accordée aux données, dans et hors de l'entreprise, cela en vaut la peine.