유니코드 주입

소개

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

유니코드 정규화

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

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

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

`\u`에서 `%`로

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

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

이모지 주입

백엔드는 이모지를 받을 때 이상하게 동작하는 경우가 있습니다. 연구자가 💋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;

이모지 목록:

3.4 KiB Raw Blame History Unescape Escape

유니코드 주입

소개

유니코드 정규화

\u에서 %로

이모지 주입

3.4 KiB

Raw Blame History

`\u`에서 `%`로