Unicode Injection

Introduction

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

Unicode Normalization

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

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

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

`\u` to `%`

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

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

Emoji Injection

백엔드는 이모지를 받을 때 이상하게 동작하는 경우가 있습니다. 연구자가 💋img src=x onerror=alert(document.domain)//💛와 같은 페이로드로 XSS를 달성한 이 글에서 발생한 일입니다.

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

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

이모지 목록:

Windows Best-Fit/Worst-fit

**이 훌륭한 게시물**에서 설명된 바와 같이, Windows에는 Best-Fit이라는 기능이 있어 ASCII 모드에서 표시할 수 없는 유니코드 문자를 유사한 문자로 대체합니다. 이는 백엔드가 특정 문자를 기대하고 있지만 다른 문자를 받게 될 때 예상치 못한 동작을 초래할 수 있습니다.

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

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

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

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

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

5.3 KiB Raw Blame History Unescape Escape