History

CPol da7335f5ee GitBook: [#3446 ] unicode injection		2022-09-02 10:02:33 +00:00
..
README.md	GitBook: [#3446 ] unicode injection	2022-09-02 10:02:33 +00:00
unicode-normalization.md	GitBook: [#3446 ] unicode injection	2022-09-02 10:02:33 +00:00

README.md

Unicode Injection

Support HackTricks and get benefits!

Do you work in a cybersecurity company? Do you want to see your company advertised in HackTricks? or do you want to have access the latest version of the PEASS or download HackTricks in PDF? Check the SUBSCRIPTION PLANS!

Discover The PEASS Family, our collection of exclusive NFTs

Get the official PEASS & HackTricks swag

Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦@carlospolopm.

Share your hacking tricks submitting PRs to the hacktricks github repo.

Introduction

Depending on how the back-end/front-end is behaving when it receives weird unicode characters an attacker might be able to bypass protections and inject arbitrary characters that could be used to abused injection vulnerabilities such as XSS or SQLi.

Unicode Normalization

Unicode normalization occurs when unicode characters are normalized to ascii characters.

One common scenario of this type of vulnerability occurs when the system is modifying somehow the input of the user after having checked it. For example, in some languages a simple call to make the input uppercase or lowercase could normalize the given input and the unicode will be transformed into ASCII generating new characters.
For more info check:

{% content-ref url="unicode-normalization.md" %} unicode-normalization.md {% endcontent-ref %}

`\u` to `%`

Unicode characters are usually represented with the \u prefix. For example the char 㱋 is \u3c4b(check it here). If a backend transforms the prefix \u in %, the resulting string will be %3c4b, which URL decoded is: <4b. And, as you can see, a < char is injected.
You could use this technique to inject any kind of char if the backend is vulnerable.
Check https://unicode-explorer.com/ to find the chars you need.

This vuln actually comes from a vulnerability a researcher found, for a more in depth explanation check https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

Back-ends something behaves weirdly when they receives emojis. That's what happened in this writeup where the researcher managed to achieve a XSS with a payload such as: 💋img src=x onerror=alert(document.domain)//💛

In this case, the error was that the server after removing the malicious characters converted the UTF-8 string from Windows-1252 to UTF-8 (basically the input encoding and the convert from encoding mismatched). Then this does not give a proper < just a weird unicode one: ‹
``So they took this output and converted again now from UTF-8 ot ASCII. This normalized the ‹ to < this is how the exploit could work on that system.
This is what happened:

<?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: