mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
65 lines
5.1 KiB
Markdown
65 lines
5.1 KiB
Markdown
# Unicode Injection
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## Introdução
|
||
|
||
Dependendo de como o back-end/front-end se comporta quando **recebe caracteres unicode estranhos**, um atacante pode ser capaz de **contornar proteções e injetar caracteres arbitrários** que podem ser usados para **explorar vulnerabilidades de injeção** como XSS ou SQLi.
|
||
|
||
## Normalização de Unicode
|
||
|
||
A normalização de Unicode ocorre quando **caracteres unicode são normalizados para caracteres ascii**.
|
||
|
||
Um cenário comum desse tipo de vulnerabilidade ocorre quando o sistema está **modificando** de alguma forma a **entrada** do usuário **após tê-la verificado**. Por exemplo, em algumas linguagens, uma simples chamada para tornar a **entrada em maiúsculas ou minúsculas** pode normalizar a entrada dada e o **unicode será transformado em ASCII**, gerando novos caracteres.\
|
||
Para mais informações, consulte:
|
||
|
||
{{#ref}}
|
||
unicode-normalization.md
|
||
{{#endref}}
|
||
|
||
## `\u` para `%`
|
||
|
||
Os caracteres unicode são geralmente representados com o **prefixo `\u`**. Por exemplo, o caractere `㱋` é `\u3c4b`([ver aqui](https://unicode-explorer.com/c/3c4B)). Se um backend **transforma** o prefixo **`\u` em `%`**, a string resultante será `%3c4b`, que decodificada em URL é: **`<4b`**. E, como você pode ver, um **caractere `<` é injetado**.\
|
||
Você poderia usar essa técnica para **injetar qualquer tipo de caractere** se o backend for vulnerável.\
|
||
Consulte [https://unicode-explorer.com/](https://unicode-explorer.com/) para encontrar os caracteres que você precisa.
|
||
|
||
Essa vulnerabilidade na verdade vem de uma vulnerabilidade que um pesquisador encontrou, para uma explicação mais detalhada, consulte [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
|
||
|
||
## Injeção de Emoji
|
||
|
||
Back-ends se comportam de forma estranha quando **recebem emojis**. Isso aconteceu em [**este relato**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) onde o pesquisador conseguiu alcançar um XSS com um payload como: `💋img src=x onerror=alert(document.domain)//💛`
|
||
|
||
Neste caso, o erro foi que o servidor, após remover os caracteres maliciosos, **converteu a string UTF-8 de Windows-1252 para UTF-8** (basicamente, a codificação de entrada e a conversão de codificação não coincidiram). Então, isso não dá um < adequado, apenas um unicode estranho: `‹`\
|
||
``Então, eles pegaram essa saída e **converteram novamente agora de UTF-8 para ASCII**. Isso **normalizou** o `‹` para `<`, assim é como a exploração poderia funcionar nesse sistema.\
|
||
Isso é o que aconteceu:
|
||
```php
|
||
<?php
|
||
|
||
$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";
|
||
|
||
$str = iconv("Windows-1252", "UTF-8", $str);
|
||
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);
|
||
|
||
echo "String: " . $str;
|
||
```
|
||
Emoji lists:
|
||
|
||
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
|
||
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
|
||
|
||
## Windows Melhor Ajuste/Pior Ajuste
|
||
|
||
Como explicado em **[este ótimo post](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, o Windows possui um recurso chamado **Melhor Ajuste** que irá **substituir caracteres unicode** que não podem ser exibidos em modo ASCII por um semelhante. Isso pode levar a **comportamentos inesperados** quando o backend está **esperando um caractere específico** mas recebe um diferente.
|
||
|
||
É possível encontrar caracteres de melhor ajuste em **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
|
||
|
||
Como o Windows geralmente converte strings unicode em strings ascii como uma das últimas partes da execução (geralmente indo de uma API com sufixo "W" para uma API com sufixo "A" como `GetEnvironmentVariableA` e `GetEnvironmentVariableW`), isso permitiria que atacantes contornassem proteções enviando caracteres unicode que seriam convertidos por último em caracteres ASCII que realizariam ações inesperadas.
|
||
|
||
No post do blog, são propostos métodos para contornar vulnerabilidades corrigidas usando uma **lista negra de caracteres**, explorar **traversais de caminho** usando [caracteres mapeados para “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) e [caracteres mapeados para “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) ou até mesmo contornar proteções de escape de shell como `escapeshellarg` do PHP ou `subprocess.run` do Python usando uma lista, isso foi feito, por exemplo, usando **aspas duplas em largura total (U+FF02)** em vez de aspas duplas, de modo que no final o que parecia ser 1 argumento foi transformado em 2 argumentos.
|
||
|
||
**Note que para um aplicativo ser vulnerável, ele precisa usar APIs do Windows "W" mas acabar chamando uma API do Windows "A", então o "Melhor ajuste" da string unicode é criado.**
|
||
|
||
**Várias vulnerabilidades descobertas não serão corrigidas, pois as pessoas não concordam sobre quem deve corrigir esse problema.**
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|