# Encoded Injection
{{INLINETOC}}
## Introduction
Le codage des caractères est principalement utilisé pour représenter des caractères, des nombres et d'autres symboles dans un format qui convient à un ordinateur pour comprendre, conserver et restituer les données. En termes simples, c'est la conversion des octets en caractères - caractères appartenant à des langues différentes comme l'anglais, le chinois, le grec ou autre. L'un des premiers système d'encodage des caractères et des plus communément utilisé est l'ASCII (code standard américain pour l'échange d'information) qui utilise 7 bits des caractères codés. Aujourd'hui, le système de codage le plus couramment utilisé est Unicode (UTF 8).
Le codage de caractères a un autre usage ou plutôt abus. Il est couramment utilisé pour l'encodage des chaînes d'injection malveillantes afin de masquer et ainsi contourner les filtres de validation d'entrée ou de tirer parti des fonctionnalités du navigateur de rendre un schéma de codage.
## Codage d'entrée – Evasion de Filtre
Les applications Web emploient généralement différents types de mécanismes de filtrage d'entrée pour limiter l'entrée qui peut être soumise par ses utilisateurs. Si ces filtres d'entrée ne sont pas suffisamment bien mis en œuvre, il est possible de glisser un ou deux caractères à travers ces filtres. Par exemple, un / peut être représenté comme 2F (hex) en ASCII, alors que le même caractère (/) est codé comme C0 AF en Unicode (2 séquences d'octets). Par conséquent, il est important pour le contrôle de filtrage d'entrée de prendre en compte le schéma de codage utilisé. Si le filtre ne détecte que les injections codées en UTF 8 un système de codage différent peut être utilisé pour contourner le filtre.
En d'autres termes, une injection codé fonctionne parce que même si un filtre d'entrée ne peut pas reconnaître ou filtrer une attaque codée, le navigateur lui l'interprètera correctement, tout en rendant la page Web.
## Codage de sortie - cohérence serveurs et navigateurs
Les navigateurs Web, afin d'assurer la cohérence dans l'affichage des pages web, sont tenus de se détecter le schéma de codage utilisé. Idéalement, cette information doit être fournie au navigateur à travers l'en-tête HTTP ("Content-Type"), comme indiqué ci-dessous:
Content-Type: text/html; charset=UTF-8
ou par une balise HTML META ("META HTTP-EQUIV"), comme indiqué ci-dessous:
C'est grâce à ces déclarations d'encodage de caractères que le navigateur comprend le jeu de caractères à utiliser lors de la conversion des octets en caractères. Le type de contenu indiqué dans l'en-tête HTTP est prioritaire sur la déclaration balise META.
Le CERT décrit ceci comme suit:\\ "De nombreuses pages Web laissent le codage de caractères (paramètre "charset" dans HTTP) non défini. Dans les versions précédentes de HTML et HTTP, l'encodage des caractères devait être par défaut ISO-8859-1 si il n'avait pas été défini. En fait, de nombreux navigateurs ont une valeur par défaut différente, de sorte qu'il n'était pas possible de se fonder sur la norme ISO-8859-1 comme étant la valeur par défaut. La version HTML 4 légitimise cela - si le codage de caractères n'est pas spécifié, aucun codage de caractères ne peut être utilisé."
Si le serveur Web ne précise pas quel encodage de caractères est utilisé, il ne peut pas dire quels sont les caractères spéciaux. La plupart du temps es les pages Web ne précisent pas le codage des caractères parce que la plupart des jeux de caractères attribuent les mêmes valeurs d'octets en dessous de 128 aux mêmes caractères. Mais quelles valeurs supérieures à 128 représentent des caractères spéciaux? Quelques systèmes de codage de caractères 16-bit ont d'autres représentations multi-octets pour les caractères spéciaux tels que "<". Certains navigateurs reconnaissent ce codage alternatif et agissent en conséquence. C'est "juste" un comportement, mais il rend les attaques utilisant des scripts malveillants beaucoup plus difficile à prévenir. Le serveur ne sait tout simplement pas quelles séquences d'octets représentent des caractères spéciaux
Par conséquent, en cas de non réception de l'information de codage de caractères à partir du serveur, le navigateur supporte les tentera de "deviner" le schéma de codage ou revient à un schéma par défaut. Dans certains cas, l'utilisateur définit explicitement l'encodage par défaut du navigateur à un schéma différent. Toute discordance par exemple dans le schéma de codage utilisé par la page web (serveur) et le navigateur peut amener le navigateur à interpréter la page d'une manière qui est involontaire ou inattendue.
## Injections codées
Tous les scénarios ci-dessous forment un sous-ensemble d'obscurcissement pour lequel divers moyens peuvent être utilisés afin de contourner les filtres d'entrée. En outre, le succès des injections codées dépend du navigateur utilisé. Par exemple, les injections codées en US-ASCII ne pouvaient auparavant réussir que dans le navigateur IE mais pas sous Firefox. Par conséquent, il convient de noter que les injections codées, dans une large mesure, dépendent du navigateur utilisé.
### Codage de base
Considérons un filtre de validation d'entrée de base qui protège contre l'injection du caractère simple quote. Dans ce cas, l'injection suivante peut facilement contourner ce filtre:
La fonction Javascript String.fromCharCode prend les valeurs Unicode données et retourne la chaîne correspondante. C'est l'une des formes les plus élémentaires d'injections codées. Un autre vecteur qui peut être utilisé pour contourner ce filtre est:
(Numeric reference)
L'exemple ci-dessus utilise les entités HTML pour construire la chaîne d'injection. Le codage de entités HTML est utilisé pour afficher des caractères qui ont une signification spéciale en HTML. Par exemple, '>' fonctionne comme un crochet de fermeture d'une balise HTML. Afin d'afficher réellement ce caractère sur la page Web les entités de caractères HTML doivent être insérées dans le source de la page. Les injections mentionnés ci-dessus sont un moyen de codage. Il existe de nombreuses autres façons pour encoder (crypter) une chaîne, dans le but de contourner le filtre ci-dessus.
### Encodage Hexadécimal
Le codage hexadécimal est un système de numérotation en base 16 c'est à dire qu'il dispose de 16 différentes valeurs de 0 à 9 et A à F pour représenter les différents caractères. Le codage hexadécimal est une autre forme de faux-fuyants qui est, parfois, utilisé pour contourner les filtres de validation d'entrée. Par exemple, la version encodée en hexadécimal de la chaîne `<__yamdwe_nowiki>2` est
Une variante de la chaîne ci-dessus est donnée ci-dessous. Peut être utilisé dans le cas ou '%' est filtré:
D'autres formes de codage sont les schémas de codage Base64 et l'octal qui peuvent être utilisés comme faux-fuyants. Bien que, chaque schéma de codage puisse ne pas fonctionner à chaque fois, un peu de tests d'essais et d'erreurs couplés avec des manipulations intelligentes peuvent certainement révéler la faille dans un filtre de validation d'entrée faiblement construit.
### Encodage UTF-7
L'encodage UTF-7 de `` donnera :
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
Pour que le script ci-dessus fonctionne, le navigateur doit interpréter la page Web comme encodés en UTF-7.
### Codages multi-octets
Le codage de largeur variable est un autre type de codage de caractères qui utilise des codes de longueurs variables pour encoder des caractères. Le codage multi-octets est un type de codage de largeur variable qui utilise un nombre variable d'octets pour représenter un caractère. L'encodage multi-octets est principalement utilisé pour coder les caractères qui appartiennent à un jeu de caractères larges par exemple Chinois, japonais et coréen.
L'encodage multi-octets a été utilisé dans le passé pour contourner les fonctions standard de validation d'entrée et réaliser des attaques cross site scripting et par injection SQL.
## Références
* http://ha.ckers.org/xss.html
* http://www.cert.org/tech_tips/malicious_code_mitigation.html
* http://www.w3schools.com/HTML/html_entities.asp
* http://www.iss.net/security_center/advice/Intrusions/2000639/default.htm
* http://searchsecurity.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid14_gci1212217_tax299989,00.html
* http://www.joelonsoftware.com/articles/Unicode.html