Unicode Normalization
Il s'agit d'un résumé de : https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Jetez un œil pour plus de détails (images prises de là).
Compréhension de l'Unicode et de la Normalisation
La normalisation Unicode est un processus qui garantit que les différentes représentations binaires des caractères sont standardisées à la même valeur binaire. Ce processus est crucial pour traiter les chaînes de caractères en programmation et en traitement des données. La norme Unicode définit deux types d'équivalence de caractères :
Équivalence canonique : Les caractères sont considérés comme équivalents canoniquement s'ils ont la même apparence et la même signification lorsqu'ils sont imprimés ou affichés.
Équivalence de compatibilité : Une forme plus faible d'équivalence 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 différemment les techniques de normalisation canonique et de compatibilité. 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, notamment 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 : En Unicode, chaque caractère ou symbole est attribué une valeur numérique appelée "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 en utilisant un octet. Cependant, les langues avec un plus grand ensemble de caractères 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 courante où les caractères ASCII sont représentés en utilisant un octet, et jusqu'à quatre octets pour les 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 d'UTF : Outre 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é de l'Unicode et de ses différentes méthodes d'encodage.
Un exemple de la manière dont Unicode normalise deux octets différents représentant le même caractère :
Une liste des caractères équivalents en 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 trouvez à l'intérieur d'une application web une valeur qui est renvoyée, vous pourriez essayer d'envoyer le "SIGNE KELVIN" (U+0212A) qui se normalise en "K" (vous pouvez l'envoyer en tant que %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 normalisation Unicode est Leonishan.
Exemples de Vulnérabilités
Contournement du 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. Cette page web, en tant que 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, elle normalise en utilisant Unicode l'entrée de l'utilisateur.
Ensuite, 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, une apostrophe est créée et une vulnérabilité d'injection SQL apparaît :
Quelques caractères Unicode intéressants
o-- %e1%b4%bcr-- %e1%b4%bf1-- %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
Modèle sqlmap
XSS (Cross Site Scripting)
Vous pourriez utiliser l'un des caractères suivants pour piéger l'application web et exploiter une XSS :
Notez que par exemple le premier caractère Unicode proposé peut être envoyé sous la forme de : %e2%89%ae ou %u226e
Fuzzing des Regex
Lorsque le backend vérifie l'entrée utilisateur avec un regex, il est possible que l'entrée soit normalisée pour le regex mais pas pour l'endroit où elle est utilisée. Par exemple, dans une redirection ou SSRF ouverte, le regex pourrait normaliser l'URL envoyée mais ensuite y accéder tel quel.
L'outil recollapse permet de générer des variations de l'entrée pour fuzz le backend. Pour plus d'informations, consultez le github et ce post.
Références
Dernière mise à jour
