C'est parce que le pare-feu applicatif web (WAF) offre un contexte d'exécution totalement différent de l'application qu'il est censé protéger qu'une attaque par smuggling (contrebande) est possible.

Le WAF ne fait bien même souvent qu'observer, et non interpréter, les requêtes. Il ne peut alors anticiper l'effet réel qu'elles produiront sur le serveur applicatif derrière lui. Le principe du smuggling consiste alors à soumettre une requête formatée d'une manière tout à fait légitime aux yeux du WAF mais dont l'interprétation sur le serveur produira des effets néfastes.

Si les premières applications de smuggling concernaient les serveurs web (voir les travaux d'Amit Klein au sujet des attaques par HTTP Response Splitting), la présentation d'Avi Douglen (ComSec Consulting) à l'occasion de la RSA Conference Europe en applique le principe aux bases de données SQL.

La partie la plus intéressante de la présentation concerne l'usage des homoglyphes : ces symboles qui à l'écran ressemblent fortement à des lettres de l'alphabet occidental mais qui ont, bien entendu, une représentation Unicode différente.

La technique est déjà bien connue pour maquiller des URL lors de campagnes de phishing, mais elle peut aussi être exploitée dans le cadre du SQL smuggling, en profitant du fait que certaines bases de données opèrent automatiquement une traduction des caractères unicodes non supportés vers le jeu de caractères local.

"Lorsqu'un caractère présent dans la requête n'existe pas dans le jeu de caractères local de la base, certaines bases de données l'ignorent, d'autres lèvent une erreur, mais d'autres encore le traduisent par le caractère le plus proche", explique Avi Douglen.

Il cite ainsi l'exemple de U+02BC, qui ressemble de très près à un guillemet simple (U+0027), et qui pourra passer outre un filtrage applicatif tout en étant convertit automatiquement par la base de données en son équivalent le plus proche... un véritable guillemet simple !

Enfin, la présentation d'Avi Douglen offre d'autres exemples moins originaux mais tout aussi problèmatiques, pour l'essentiel basés sur une utilisation "créative" des espaces et des caractères de commentaires (par exemple le fameux exec("?INS' + "?SERT INTO').

L'auteur recommande, bien entendu, de ne pas autoriser la traduction automatique des caractères unicode non supportés, mais aussi de privilégier une approche par liste blanche des caractères supportés.

A lire : http://www.comsecglobal.com/FrameWork/Upload/SQL_smuggling.pdf