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を達成したこのレポートで起こったことです。

この場合、サーバーは悪意のある文字を削除した後、UTF-8文字列をWindows-1252から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.6 KiB Raw Blame History Unescape Escape

Unicode Injection

Introduction

Unicode Normalization

\u to %

Emoji Injection

3.6 KiB

Raw Blame History

`\u` to `%`