Normalisation Unicode

Reading time: 7 minutes

Ceci est un résumé de : https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Consultez-le pour plus de détails (images prises de là).

Comprendre Unicode et la Normalisation

La normalisation Unicode est un processus qui garantit que différentes représentations binaires de caractères sont standardisées à la même valeur binaire. Ce processus est crucial pour traiter des chaînes dans la programmation et le traitement des données. La norme Unicode définit deux types d'équivalence de caractères :

1. Équivalence Canonique : Les caractères sont considérés comme équivalents canoniquement s'ils ont la même apparence et signification lorsqu'ils sont imprimés ou affichés.
2. Équivalence de Compatibilité : Une forme d'équivalence plus faible où les caractères peuvent représenter le même caractère abstrait mais peuvent être affichés différemment.

Il existe quatre algorithmes de normalisation Unicode : NFC, NFD, NFKC et NFKD. Chaque algorithme utilise les techniques de normalisation canonique et de compatibilité de manière différente. Pour une compréhension plus approfondie, vous pouvez explorer ces techniques sur Unicode.org.

Points Clés sur l'Encodage Unicode

Comprendre l'encodage Unicode est essentiel, surtout lorsqu'il s'agit de problèmes d'interopérabilité entre différents systèmes ou langues. Voici les points principaux :

• Points de Code et Caractères : Dans Unicode, chaque caractère ou symbole se voit attribuer une valeur numérique connue sous le nom de "point de code".
• Représentation en Octets : Le point de code (ou caractère) est représenté par un ou plusieurs octets en mémoire. Par exemple, les caractères LATIN-1 (courants dans les pays anglophones) sont représentés à l'aide d'un octet. Cependant, les langues avec un ensemble de caractères plus large nécessitent plus d'octets pour la représentation.
• Encodage : Ce terme fait référence à la manière dont les caractères sont transformés en une série d'octets. UTF-8 est une norme d'encodage répandue où les caractères ASCII sont représentés à l'aide d'un octet, et jusqu'à quatre octets pour d'autres caractères.
• Traitement des Données : Les systèmes traitant des données doivent être conscients de l'encodage utilisé pour convertir correctement le flux d'octets en caractères.
• Variantes de UTF : En plus de UTF-8, il existe d'autres normes d'encodage comme UTF-16 (utilisant un minimum de 2 octets, jusqu'à 4) et UTF-32 (utilisant 4 octets pour tous les caractères).

Il est crucial de comprendre ces concepts pour gérer efficacement et atténuer les problèmes potentiels découlant de la complexité d'Unicode et de ses diverses méthodes d'encodage.

Un exemple de la façon dont Unicode normalise deux octets différents représentant le même caractère :

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

Une liste de caractères équivalents Unicode peut être trouvée ici : https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html et https://0xacb.com/normalization_table

Découverte

Si vous pouvez trouver à l'intérieur d'une application web une valeur qui est renvoyée, vous pourriez essayer d'envoyer ‘KELVIN SIGN’ (U+0212A) qui se normalise en "K" (vous pouvez l'envoyer sous la forme %e2%84%aa). Si un "K" est renvoyé, alors, une sorte de normalisation Unicode est effectuée.

Autre exemple : %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 après unicode est Leonishan.

Exemples vulnérables

Contourner le filtre d'injection SQL

Imaginez une page web qui utilise le caractère ' pour créer des requêtes SQL avec l'entrée de l'utilisateur. Ce web, comme mesure de sécurité, supprime toutes les occurrences du caractère ' de l'entrée de l'utilisateur, mais après cette suppression et avant la création de la requête, il normalise l'entrée de l'utilisateur en utilisant Unicode.

Alors, un utilisateur malveillant pourrait insérer un caractère Unicode différent équivalent à ' (0x27) comme %ef%bc%87, lorsque l'entrée est normalisée, un guillemet simple est créé et une vulnérabilité d'injection SQL apparaît :

Quelques caractères Unicode intéressants

• o -- %e1%b4%bc
• r -- %e1%b4%bf
• 1 -- %c2%b9
• = -- %e2%81%bc
• / -- %ef%bc%8f
• --- %ef%b9%a3
• #-- %ef%b9%9f
• *-- %ef%b9%a1
• ' -- %ef%bc%87
• " -- %ef%bc%82
• | -- %ef%bd%9c

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

modèle sqlmap

GitHub - carlospolop/sqlmap_to_unicode_template

XSS (Cross Site Scripting)

Vous pouvez utiliser l'un des caractères suivants pour tromper l'application web et exploiter un XSS :

Notez que, par exemple, le premier caractère Unicode proposé peut être envoyé sous la forme : %e2%89%ae ou %u226e

Fuzzing Regexes

Lorsque le backend vérifie l'entrée utilisateur avec une regex, il se peut que l'entrée soit normalisée pour la regex mais pas pour l'endroit où elle est utilisée. Par exemple, dans un Open Redirect ou SSRF, la regex peut normaliser l'URL envoyée mais ensuite y accéder telle quelle.

L'outil recollapse **** permet de générer des variations de l'entrée pour fuzz le backend. Pour plus d'infos, consultez le github et ce post.

Débordement Unicode

D'après ce blog, la valeur maximale d'un octet est 255, si le serveur est vulnérable, un débordement peut être conçu pour produire un caractère ASCII spécifique et inattendu. Par exemple, les caractères suivants seront convertis en A :

• 0x4e41
• 0x4f41
• 0x5041
• 0x5141

Références

• https://labs.spotify.com/2013/06/18/creative-usernames/
• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work
• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html
• https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows