Unicode Normalization

Reading time: 10 minutes

これは次の要約です: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/。詳細については確認してください（画像はそこから取得されています）。

Understanding Unicode and Normalization

Unicode正規化は、文字の異なるバイナリ表現が同じバイナリ値に標準化されるプロセスです。このプロセスは、プログラミングやデータ処理における文字列の取り扱いにおいて重要です。Unicode標準は、2種類の文字の同等性を定義しています：

1. Canonical Equivalence: 文字が印刷または表示されたときに同じ外観と意味を持つ場合、それらは正規同等と見なされます。
2. Compatibility Equivalence: 文字が同じ抽象的な文字を表す可能性があるが、異なる方法で表示される場合の弱い同等性の形式です。

Unicode正規化アルゴリズムは4つあります：NFC、NFD、NFKC、NFKD。それぞれのアルゴリズムは、正規および互換性の正規化技術を異なる方法で使用します。より深く理解するためには、Unicode.orgでこれらの技術を探ることができます。

Key Points on Unicode Encoding

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つの異なるバイトをどのように正規化するかの例：

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

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インジェクションフィルターバイパス

ユーザー入力を使用して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

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

sqlmap テンプレート

GitHub - carlospolop/sqlmap_to_unicode_template

XSS (クロスサイトスクリプティング)

次のいずれかの文字を使用して、ウェブアプリを欺き、XSSを悪用することができます：

例えば、提案された最初のUnicode文字は、%e2%89%aeまたは%u226eとして送信できます。

ファジング正規表現

バックエンドがユーザー入力を正規表現でチェックしている場合、入力が正規表現のために正規化されているが、使用される場所では正規化されていない可能性があります。例えば、オープンリダイレクトやSSRFでは、正規表現が送信されたURLを正規化しているかもしれませんが、その後そのままアクセスしています。

ツールrecollapseは、バックエンドをファジングするために入力のバリエーションを生成することを可能にします。詳細については、githubとこの投稿を確認してください。

Unicodeオーバーフロー

このブログによると、バイトの最大値は255であり、サーバーが脆弱な場合、特定の予期しないASCII文字を生成するためにオーバーフローを作成できます。例えば、次の文字はAに変換されます：

• 0x4e41
• 0x4f41
• 0x5041
• 0x5141

参考文献

• https://labs.spotify.com/2013/06/18/creative-usernames/
• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work
• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html
• https://portswigger.net/research/bypassing-character-blocklists-with-unicode-overflows