Italian - Ht
HackTricks Training Twitter Linkedin Sponsor

Unicode Injection

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Introduzione

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

Normalizzazione Unicode

La normalizzazione Unicode avviene 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 alcuni linguaggi una semplice chiamata per rendere l'input maiuscolo o minuscolo potrebbe normalizzare l'input fornito e l'unicode verrà trasformato in ASCII generando nuovi caratteri. Per ulteriori informazioni, consulta:

pageUnicode Normalization

\u to %

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

Questa vulnerabilità in realtà deriva da una vulnerabilità trovata da un ricercatore, per una spiegazione più approfondita consulta https://www.youtube.com/watch?v=aUsAHb0E7Cg

Iniezione di Emoji

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

In questo caso, l'errore era che il server dopo aver rimosso i caratteri maligni ha convertito la stringa UTF-8 da Windows-1252 a UTF-8 (in pratica l'encoding dell'input e la conversione dell'encoding non corrispondevano). Quindi questo non restituisce un corretto < ma uno strano unicode: ‹ ``Quindi hanno preso questo output e convertito di nuovo da UTF-8 ad ASCII. Questo ha normalizzato ‹ in < ed è così che l'exploit poteva 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;

Elenco di emoji:

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousReverse Tab NabbingNextUnicode Normalization

Last updated