Google Hacking et SQL Injection bras dessus, bras dessous
... ou le hacking à la portée des caniches, article signé par Mike Sutton de SpyDinamics. L'auteur part d'un constat statistique émis par le Mitre. Selon cet organisme, le hit parade des leviers d'attaque s'établit comme suit : Cross Site Scripting (21.5%) SQL Injection (14%) PHP includes (9.5%) Buffer overflows (7.9%) A ce classement, Sutton ajoute une seconde remarque : il serait inconscient d'accuser systématiquement l'éditeur à chaque intrusion ou tentative d'intrusion de la part d'un black hat... il faut également compter sur les programmes établis par les usagers eux-mêmes, programmes qui ne sont pas toujours d'une perfection absolue, loin s'en faut. Cette vérité première que connaissait chaque modeste pondeur de code Basic ou du langage dBase/Xbase s'est quelque peu évaporée avec la génération montante des programmeurs « à outils intégrés ». PHP et SQL mal maitrisé sont les deux mamelles du pirate. Et plus particulièrement SQL, puisqu'il ne peut se monter un blog, un Web, un « machin » interactif sur la Grande Toile sans y voir quelques lignes de MySQL ou proche cousin. Oui, mais voilà, comment prouver cette vulnérabilité du « mauvais code », s'interroge Sutton. Lancer une attaque sauvage contre des sites innocents ? Mais c'est réprimé par la loi ! Autant passer par un intermédiaire, que l'on chargera à la fois du travail de diffusion du pentest, du tri et de la récolte des informations... le meilleur amis de l'internaute, Google bien sur. Johnny « I Hack Stuff » Long ne pourrait le nier. Et Sutton de lancer une requête Get sur un résultat typique d'un champ SQL, puis d'obtenir des résultats immédiats. Sur un échantillonnage de 1000 sites, 11% (80 sites) affichent une erreur SQL en réponse à ladite requête. Certes, un retour d'erreur n'est pas une faille... ce n'est que le premier pas d'une attaque. Il en faut encore quelques autres pour parvenir aux données, mais cette méthode aura au moins permis de découvrir le défaut initial exploitable. Rappelons que les principaux scandales de hack bancaires révélés courant 2005 reposaient précisément sur des attaques par injection SQL.
