Unicode Normalization
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Este é um resumo de: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Confira para mais detalhes (imagens retiradas de lá).
Compreendendo Unicode e Normalização
A normalização Unicode é um processo que garante que diferentes representações binárias de caracteres sejam padronizadas para o mesmo valor binário. Este processo é crucial ao lidar com strings em programação e processamento de dados. O padrão Unicode define dois tipos de equivalência de caracteres:
Equivalência Canônica: Caracteres são considerados canonicamente equivalentes se têm a mesma aparência e significado quando impressos ou exibidos.
Equivalência de Compatibilidade: Uma forma mais fraca de equivalência onde caracteres podem representar o mesmo caractere abstrato, mas podem ser exibidos de maneira diferente.
Existem quatro algoritmos de normalização Unicode: NFC, NFD, NFKC e NFKD. Cada algoritmo emprega técnicas de normalização canônica e de compatibilidade de maneira diferente. Para uma compreensão mais aprofundada, você pode explorar essas técnicas em Unicode.org.
Pontos Chave sobre Codificação Unicode
Compreender a codificação Unicode é fundamental, especialmente ao lidar com problemas de interoperabilidade entre diferentes sistemas ou idiomas. Aqui estão os principais pontos:
Pontos de Código e Caracteres: No Unicode, cada caractere ou símbolo é atribuído a um valor numérico conhecido como "ponto de código".
Representação em Bytes: O ponto de código (ou caractere) é representado por um ou mais bytes na memória. Por exemplo, caracteres LATIN-1 (comuns em países de língua inglesa) são representados usando um byte. No entanto, idiomas com um conjunto maior de caracteres precisam de mais bytes para representação.
Codificação: Este termo refere-se a como os caracteres são transformados em uma série de bytes. UTF-8 é um padrão de codificação prevalente onde caracteres ASCII são representados usando um byte, e até quatro bytes para outros caracteres.
Processamento de Dados: Sistemas que processam dados devem estar cientes da codificação utilizada para converter corretamente o fluxo de bytes em caracteres.
Variantes de UTF: Além do UTF-8, existem outros padrões de codificação como UTF-16 (usando um mínimo de 2 bytes, até 4) e UTF-32 (usando 4 bytes para todos os caracteres).
É crucial compreender esses conceitos para lidar efetivamente e mitigar potenciais problemas decorrentes da complexidade do Unicode e seus vários métodos de codificação.
Um exemplo de como o Unicode normaliza dois bytes diferentes representando o mesmo caractere:
Uma lista de caracteres equivalentes em Unicode pode ser encontrada aqui: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html e https://0xacb.com/normalization_table
Descoberta
Se você conseguir encontrar dentro de um webapp um valor que está sendo retornado, você pode tentar enviar ‘KELVIN SIGN’ (U+0212A) que normaliza para "K" (você pode enviá-lo como %e2%84%aa
). Se um "K" for retornado, então, algum tipo de normalização Unicode está sendo realizada.
Outro exemplo: %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
após unicode é Leonishan
.
Exemplos Vulneráveis
Bypass de filtro de SQL Injection
Imagine uma página da web que está usando o caractere '
para criar consultas SQL com a entrada do usuário. Esta web, como uma medida de segurança, deleta todas as ocorrências do caractere '
da entrada do usuário, mas após essa deleção e antes da criação da consulta, ela normaliza usando Unicode a entrada do usuário.
Então, um usuário malicioso poderia inserir um caractere Unicode diferente equivalente a ' (0x27)
como %ef%bc%87
, quando a entrada for normalizada, uma aspa simples é criada e uma vulnerabilidade de SQL Injection aparece:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F910640767-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjzQiXe8oFAkPoN0MXcUG%252Fuploads%252Fgit-blob-cfdae82573fcb9876021784f9e2365e155afe1f0%252Fimage%2520%28702%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=e88b4987&sv=1)
Alguns caracteres Unicode interessantes
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
sqlmap template
XSS (Cross Site Scripting)
Você pode usar um dos seguintes caracteres para enganar o webapp e explorar um XSS:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F910640767-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjzQiXe8oFAkPoN0MXcUG%252Fuploads%252Fgit-blob-5059eac82a622d250b5734d5f71c9ee7dcc6f2f8%252Fimage%2520%28312%29%2520%282%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=32a0c15d&sv=1)
Observe que, por exemplo, o primeiro caractere Unicode proposto pode ser enviado como: %e2%89%ae
ou como %u226e
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F910640767-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FjzQiXe8oFAkPoN0MXcUG%252Fuploads%252Fgit-blob-83837382a41f727d2a3b89c3429d204be1dd14c0%252Fimage%2520%28215%29%2520%281%29%2520%281%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=3e4a3cd8&sv=1)
Fuzzing Regexes
Quando o backend está verificando a entrada do usuário com uma regex, pode ser possível que a entrada esteja sendo normalizada para a regex, mas não para onde está sendo usada. Por exemplo, em um Open Redirect ou SSRF, a regex pode estar normalizando a URL enviada, mas depois acessando-a como está.
A ferramenta recollapse **** permite gerar variações da entrada para fuzzar o backend. Para mais informações, consulte o github e este post.
References
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated