Unicode Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
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
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:
Emoji lists:
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)
