Unicode Injection

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Introduzione

A seconda di come si comporta il back-end/front-end quando riceve caratteri unicode strani, un attaccante potrebbe essere in grado di bypassare le protezioni e iniettare caratteri arbitrari che potrebbero essere utilizzati per sfruttare vulnerabilità di iniezione come XSS o SQLi.

Normalizzazione Unicode

La normalizzazione Unicode si verifica quando i caratteri unicode vengono normalizzati in caratteri ascii.

Uno scenario comune di questo tipo di vulnerabilità si verifica quando il sistema sta modificando in qualche modo l'input dell'utente dopo averlo controllato. Ad esempio, in alcune lingue una semplice chiamata per rendere l'input maiuscolo o minuscolo potrebbe normalizzare l'input fornito e il unicode verrà trasformato in ASCII generando nuovi caratteri. Per ulteriori informazioni, controlla:

Unicode Normalization

\u a %

I caratteri Unicode sono solitamente rappresentati con il prefisso \u. Ad esempio, il carattere 㱋 è \u3c4b(controllalo qui). Se un backend trasforma il prefisso \u in %, la stringa risultante sarà %3c4b, che decodificata in URL è: <4b. E, come puoi vedere, un carattere < è iniettato. Potresti usare questa tecnica per iniettare qualsiasi tipo di carattere se il backend è vulnerabile. Controlla https://unicode-explorer.com/ per trovare i caratteri di cui hai bisogno.

Questa vulnerabilità proviene effettivamente da una vulnerabilità trovata da un ricercatore, per una spiegazione più approfondita controlla https://www.youtube.com/watch?v=aUsAHb0E7Cg

Iniezione di Emoji

I back-end si comportano in modo strano quando ricevono emoji. Questo è ciò che è successo in questo writeup dove il ricercatore è riuscito a ottenere un XSS con un payload come: 💋img src=x onerror=alert(document.domain)//💛

In questo caso, l'errore era che il server, dopo aver rimosso i caratteri dannosi, ha convertito la stringa UTF-8 da Windows-1252 a UTF-8 (fondamentalmente l'encoding dell'input e la conversione dall'encoding non corrispondevano). Quindi questo non dà un corretto < solo uno strano unicode: ‹ ``Quindi hanno preso questo output e convertito di nuovo ora da UTF-8 a ASCII. Questo ha normalizzato il ‹ in < e questo è come l'exploit potrebbe funzionare su quel sistema. Questo è ciò che è successo:

<?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://unicode.org/emoji/charts-14.0/full-emoji-list.html

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.