Unicode Normalization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This is a summary of: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Check a look for further details (images taken form there).
Unicode normalizationは、異なるバイナリ表現の文字が同じバイナリ値に標準化されるプロセスです。このプロセスは、プログラミングやデータ処理において文字列を扱う際に重要です。Unicode標準は、2種類の文字の同等性を定義しています：
Canonical Equivalence: 文字が印刷または表示されたときに同じ外観と意味を持つ場合、それらは正規同等と見なされます。
Compatibility Equivalence: 文字が同じ抽象的な文字を表す可能性があるが、異なる方法で表示されることができる弱い同等性の形式です。
Unicode正規化アルゴリズムは4つあります：NFC、NFD、NFKC、NFKD。それぞれのアルゴリズムは、正規化技術と互換性の正規化技術を異なる方法で使用します。より深く理解するためには、Unicode.orgでこれらの技術を探求できます。
Unicodeエンコーディングを理解することは、特に異なるシステムや言語間の相互運用性の問題を扱う際に重要です。主なポイントは以下の通りです：
Code Points and Characters: Unicodeでは、各文字または記号に「コードポイント」として知られる数値が割り当てられています。
Bytes Representation: コードポイント（または文字）は、メモリ内で1つ以上のバイトで表されます。たとえば、LATIN-1文字（英語圏で一般的）は1バイトを使用して表されます。しかし、より多くの文字セットを持つ言語は、表現のためにより多くのバイトが必要です。
Encoding: この用語は、文字がバイトの系列に変換される方法を指します。UTF-8は一般的なエンコーディング標準で、ASCII文字は1バイトで表され、他の文字には最大4バイトが使用されます。
Processing Data: データを処理するシステムは、バイトストリームを正しく文字に変換するために使用されるエンコーディングを認識している必要があります。
Variants of UTF: UTF-8の他にも、UTF-16（最小2バイト、最大4バイトを使用）やUTF-32（すべての文字に4バイトを使用）などの他のエンコーディング標準があります。
これらの概念を理解することは、Unicodeの複雑さとそのさまざまなエンコーディング方法から生じる潜在的な問題を効果的に扱い、軽減するために重要です。
Unicodeが同じ文字を表す2つの異なるバイトをどのように正規化するかの例：
Unicodeの同等文字のリストはここにあります: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html と https://0xacb.com/normalization_table
ウェブアプリ内でエコーされる値を見つけることができれば、‘KELVIN SIGN’ (U+0212A) を送信してみることができます。これは "K" に 正規化されます（%e2%84%aa として送信できます）。"K" がエコーされる場合、何らかの Unicode正規化 が行われています。
他の 例: %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 は unicode 後に Leonishan になります。
ユーザー入力を使用してSQLクエリを作成するために、文字 ' を使用しているウェブページを想像してください。このウェブは、セキュリティ対策として、ユーザー入力から ' のすべての出現を 削除 しますが、その削除の後、クエリの作成の前に、ユーザーの入力を Unicode を使用して 正規化 します。
その後、悪意のあるユーザーは、' (0x27) に相当する別のUnicode文字 %ef%bc%87 を挿入することができ、入力が正規化されると、シングルクォートが作成され、SQLインジェクションの脆弱性が現れます：
いくつかの興味深いUnicode文字
o -- %e1%b4%bc
r -- %e1%b4%bf
1 -- %c2%b9
= -- %e2%81%bc
/ -- %ef%bc%8f
--- %ef%b9%a3
#-- %ef%b9%9f
*-- %ef%b9%a1
' -- %ef%bc%87
" -- %ef%bc%82
| -- %ef%bd%9c
次の文字のいずれかを使用して、ウェブアプリを欺き、XSSを悪用することができます：
例えば、提案された最初のUnicode文字は、%e2%89%aeまたは%u226eとして送信できます。
バックエンドがユーザー入力を正規表現でチェックしている場合、入力が正規表現のために正規化されているが、使用される場所では正規化されていない可能性があります。例えば、オープンリダイレクトやSSRFでは、正規表現が送信されたURLを正規化しているかもしれませんが、その後そのままアクセスしています。
ツールrecollapse ****は、バックエンドをファジングするために入力のバリエーションを生成することを可能にします。詳細については、githubとこの投稿を確認してください。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
