IDF

Ces derniers temps, Microsoft avait attiré les feux de la rampe après qu'une série d'attaques par injection SQL a touché un certain nombre de serveurs. Dans la pratique, les prémices de ces attaques laissaient supposer des proportions presque épiques à cette vague, mais le phénomène a été rapidement maîtrisé.

Il a tout de même eu le mérite de provoquer des attentes et des réactions vives chez les administrateurs, car une situation chez Microsoft n'a pas été réglée. Depuis la sortie de Windows Server 2008, l'architecture de communication a été grandement modifiée. Elle prend désormais appui sur Windows Communication Foundation, dont la version 7.0 d'Internet Information Service (IIS) se sert également.

Le problème de cette vague d'attaques était donc qu'elle visait des configurations basées sur IIS et qui fonctionnaient en coordination avec SQL Server. Des requêtes SQL spécialement conçues avaient la capacité de provoquer des dommages à une structure SQL. Il y avait bien entendu un problème à corriger du côté de Microsoft, mais le souci venait également du fait que toute la structure basée sur IIS 7.0 ne dispose pas des outils habituels pour régler ces situations.

Dans la ligne de mire, l'outil UrlScan Filter. Sorti en version 1.0 en 2001, sa dernière mouture officielle et finale est la 2.5, disponible depuis l'année dernière, mais uniquement jusqu'à IIS 6.0. De fait, IIS 7.0 n'est pas compatible, car fonctionnant de manière très différente. Microsoft travaillait déjà sur la version 3.0 de son outil, mais la vague d'attaques a accéléré le mouvement.

UrlScan Filter 3.0 est donc disponible en version bêta, et s'adapte à la manière dont IIS 7.0 peut interpréter les requêtes venues du Web. UrlScan est une ligne de défense, mais pas LA ligne de défense. Il s'agit d'un outil potentiellement puissant, mais qui ne fonctionne pas à la manière d'un antivirus : il ne suffit pas de l'installer pour que tout soit géré automatiquement. Il permet de définir clairement les limites entre les diverses fonctionnalités qui peuvent être appelées depuis une requête SQL. Il fut par exemple très utile pour contrôler dans le passé les requêtes qui faisaient appel au protocole WebDAV. Dans le cas où ce dernier n'est plus utilisé dans une entreprise donnée, l'administrateur peut alors entièrement filtrer tous les appels relatifs.

Microsoft propose également un autre outil très utile en version bêta, qui permet de scanner le code source des pages pour mettre en avant les possibles portions qui seraient vulnérables justement aux injections SQL. Enfin, l'éditeur a développé Scrawlr, en partenariat avec HP. Cet utilitaire se destine aux sites web déjà en place et permet de surveiller les paramètres de chaque page à la recherche de vulnérabilités connues aux injections SQL.

Finalement, à quelque chose malheur est bon.