Pascal MESSAGER, dba sqlserver

C'est un classique. Dans les dix premières leçons de l'apprenti-pirate pré-adolescent. Pour pirater un site web, il suffit de taper ces deux mots "injection sql" dans Google, et il nous tombe 500 000 hits. 500 000 modes d'emploi de hack. Et ça marche !

Parce que c'est simple. Simple à pleurer. Il suffit de connaître un caractère présent sur le clavier. Un tout petit, à peine quelques pixels à l'écran. Mais il ouvre la porte de quantité de sites web aussi peu protégés qu'un vieux moulin abandonné en Haute-Provence, dans lequel entrent et sortent des nuées de cigales stridulentes.

Une vulgaire apostrophe. Située sous le chiffre 4 d'un clavier AZERTY. Voilà la clé magique qui menace la sécurité de votre serveur de bases de données.

Vous ne me croyez pas ? Vous avez tort. C'est simple à pleurer vous dis-je.

Travaux Pratiques

Oncques estoit votre beau site web, chargé de tous vos espoirs de richesse e-commerciale. Evidemment, vous prévoyâtes à l'endroit de vos estimés clients zé partenaires, un accès privilégié. Privilèges abolis un Quatre-Août pour les naïfs, soit dit en passant.

Pour accéder à ce club de nantis, les susdits se doivent de décliner leur identité. Le programmeur que vous chargeâtes de cette vile tâche étant fainéant par nature, il copicolla le code html d'un site concurrent et proposa deux minuscules zones de saisie. L'une baptisée "Login" et l'autre "Password", à moins qu'il ne s'astreignit à la francisation.

L'internaute honnête et cynophile saisira donc son sésame. Par exemple
Login = dupond
Password = medor
Et la chevillette cherra.

Mais supposons notre internaute, privilégié disions-nous donc non concerné par le Quatre-Août, être de cette noble engeance aristocratique et disposer d'une particule en son nom (et vaguement irlandais de plus).

Login = O'Neil d'Estrées d'Harcourt
Password = n'importe nawak

Hélas, ô rage, ô désespoir, s'abat alors le couperet fatal du bug et, au lieu d'afficher la page web due à son rang, voici qu'apparait une absconse insulte :


Perdu ! Votre site a cédé sous les coups de butoir de l'apostrophe scélérate et révélé sa vulnérabilité. Le pirate y est désormais comme chez lui.

Que c'est-il passé ?
L'apostrophe est chez SQL, le langage d'accès à la base de données, le délimiteur de chaine de caractères. Le programmeur a construit la requête autour du login, sans envisager le cas de l'apostrophe présente. Résultat, tout ce qui est après cette apostrophe est interprété par SQL comme du code exécutable. Dans l'exemple ci-dessus "Neil d" provoque une erreur de syntaxe d'où le message peu amène.

Mais si au lieu d'une instruction erronée après l'apostrophe, l'internaute saisit une instruction SQL valide ?

Login = ' or 1=1 --
Password = onsenfout

Je vous passe les détails techniques, mais la saisie ci-dessus suffit à tromper le contrôle de sécurité et donner accès à la page web protégée. Mais on peut faire bien pire et pénétrer le système entier.

Allons ! Est-ce vraiment une menace sérieuse ?
Oui, hélas. Pour avoir fait des petits essais, un site web sur dix est ainsi vulnérable. Y-compris des sites très prestigieux dans le secteur de la haute finance !

Faites le test sur votre site web. Insérez une petite apostrophe, une toute petite. Si ça plante, vous serez bientôt visité par un horrible bot aux intentions mafieuses venu du tréfond du Balozhikstan...

Vous connaissez la loi de Pareto ? Elle stipule que dans tout système, 20% des ressources génèrent 80% de la productivité. Les mauvaises langues ajoutent même que c'est récursif.
Inversement, 20% des points de mauvaise qualité générent 80% des pertes.

J'ignore si c'est vrai parmi nos chers gouvernants, mais en ce qui concerne les performances d'une base de données, ça marche. Si 20% des requêtes font presque tout le boulot, 20% des requêtes, pas forcément les mêmes, sont responsables de 80% des ralentissements.

C'est facile à démontrer.

Une bonne vieille trace de derrière les fagots dans SQL Server (gestionnaire de profils pour les initiés) pour espionner pendant quelques heures qui fait quoi, et voilà. Un petit tri par ordre décroissant de gloutonnerie mémoire ou I/O disque par dessus, et les coupables se retrouvent immédiatement sous les feux de la rampe.

C'est ce que je fais dorénavant sur chaque serveur SQL que je suis amené à auditer. Et ça marche à tous les coups. Suffit ensuite d'étrangler le coupable et le convaincre de modérer sa consommation de ressources (un chti t'index ou une chtite correction de bug). Le résultat est généralement spectaculaire en terme d'améliorations de performances. Le client est ravi, son serveur vient de prendre un coup de jeune et prolonge la vie de son application pour quelques années.

Je lui fais un petit discours sur la chance qu'il a eu de me rencontrer et lui présente une grosse facture. Il paye avec un grand sourire et me recommande à ses amis.

Moralité de la loi de Pareto : concentrons-nous d'abord sur ce qui paye. Et passons le reste du temps sur la plage.