Unicode Injection

Reading time: 3 minutes

tip

Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

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 è stato 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 unicode strano: ‹
``Quindi hanno preso questo output e convertito di nuovo ora da UTF-8 a ASCII. Questo ha normalizzato il ‹ in <, ecco come l'exploit potrebbe funzionare su quel sistema.
Questo è ciò che è successo:

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;

Liste di emoji:

tip

Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks