# Unicode Injection

{{#include ../../banners/hacktricks-training.md}}

## Introduction

백엔드/프론트엔드가 **이상한 유니코드 문자를 받을 때** 어떻게 동작하는지에 따라 공격자는 **보호를 우회하고 임의의 문자를 주입**할 수 있으며, 이는 XSS 또는 SQLi와 같은 **주입 취약점을 악용**하는 데 사용될 수 있습니다.

## Unicode Normalization

유니코드 정규화는 **유니코드 문자가 ASCII 문자로 정규화**될 때 발생합니다.

이 유형의 취약점의 일반적인 시나리오는 시스템이 **사용자의 입력을 확인한 후** 어떤 식으로든 **수정**할 때 발생합니다. 예를 들어, 일부 언어에서는 **입력을 대문자 또는 소문자로** 만드는 간단한 호출이 주어진 입력을 정규화할 수 있으며, **유니코드는 ASCII로 변환**되어 새로운 문자를 생성합니다.\
자세한 내용은 다음을 확인하세요:

{{#ref}}
unicode-normalization.md
{{#endref}}

## `\u` to `%`

유니코드 문자는 일반적으로 **`\u` 접두사**로 표현됩니다. 예를 들어 문자 `㱋`는 `\u3c4b`입니다([여기에서 확인](https://unicode-explorer.com/c/3c4B)). 만약 백엔드가 **`\u` 접두사를 `%`로 변환**하면, 결과 문자열은 `%3c4b`가 되며, URL 디코딩하면: **`<4b`**가 됩니다. 그리고, 보시다시피, **`<` 문자가 주입**됩니다.\
백엔드가 취약하다면 이 기술을 사용하여 **어떤 종류의 문자도 주입**할 수 있습니다.\
필요한 문자를 찾으려면 [https://unicode-explorer.com/](https://unicode-explorer.com/)를 확인하세요.

이 취약점은 실제로 연구자가 발견한 취약점에서 비롯된 것으로, 더 깊이 있는 설명은 [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)에서 확인하세요.

## Emoji Injection

백엔드는 **이모지를 받을 때** 이상하게 동작하는 경우가 있습니다. 연구자가 `💋img src=x onerror=alert(document.domain)//💛`와 같은 페이로드로 XSS를 달성한 [**이 글**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209)에서 발생한 일입니다.

이 경우, 서버가 악성 문자를 제거한 후 **Windows-1252에서 UTF-8로 UTF-8 문자열을 변환**했기 때문에 오류가 발생했습니다(기본적으로 입력 인코딩과 변환 인코딩이 불일치했습니다). 그러면 제대로 된 <가 아니라 이상한 유니코드인 `‹`가 생성됩니다.\
``그래서 그들은 이 출력을 가져와서 **이제 UTF-8에서 ASCII로 다시 변환**했습니다. 이렇게 하면 `‹`가 ` <`로 **정규화**되어 이 시스템에서 익스플로잇이 작동할 수 있었습니다.\
이것이 발생한 일입니다:
```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;
```
이모지 목록:

- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)

## Windows Best-Fit/Worst-fit

**[이 훌륭한 게시물](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**에서 설명된 바와 같이, Windows에는 **Best-Fit**이라는 기능이 있어 ASCII 모드에서 표시할 수 없는 유니코드 문자를 유사한 문자로 **대체**합니다. 이는 백엔드가 **특정 문자를 기대**하고 있지만 다른 문자를 받게 될 때 **예상치 못한 동작**을 초래할 수 있습니다.

**[https://worst.fit/mapping/](https://worst.fit/mapping/)**에서 best-fit 문자를 찾을 수 있습니다.

Windows는 일반적으로 실행의 마지막 부분에서 유니코드 문자열을 ASCII 문자열로 변환하므로(보통 "W" 접미사가 있는 API에서 "A" 접미사가 있는 API로 이동, 예: `GetEnvironmentVariableA`와 `GetEnvironmentVariableW`) 공격자는 유니코드 문자를 보내어 보호를 우회할 수 있습니다. 이 문자는 마지막에 ASCII 문자로 변환되어 예상치 못한 동작을 수행하게 됩니다.

블로그 게시물에서는 **문자 블랙리스트**를 사용하여 수정된 취약점을 우회하는 방법, [“/“ (0x2F)에 매핑된 문자](https://worst.fit/mapping/#to%3A0x2f)와 [“\“ (0x5C)에 매핑된 문자](https://worst.fit/mapping/#to%3A0x5c)를 사용하여 **경로 탐색**을 악용하는 방법, 또는 PHP의 `escapeshellarg`나 Python의 `subprocess.run`과 같은 셸 이스케이프 보호를 우회하는 방법이 제안되었습니다. 예를 들어, **전각 따옴표 (U+FF02)**를 사용하여 최종적으로 1개의 인수처럼 보이는 것이 2개의 인수로 변환되었습니다.

**앱이 취약하려면 "W" Windows API를 사용해야 하지만 "A" Windows API를 호출해야 하므로 유니코드 문자열의 "Best-fit"이 생성됩니다.**

**여러 발견된 취약점은 이 문제를 누가 해결해야 하는지에 대한 합의가 없기 때문에 수정되지 않을 것입니다.**

{{#include ../../banners/hacktricks-training.md}}