Japanese - Ht

Unicode Normalization

Support HackTricks

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

Unicodeと正規化の理解

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

  1. 標準同等性: 文字が印刷または表示されたときに同じ外観と意味を持つ場合、それらは標準的に同等と見なされます。

  2. 互換性同等性: 文字が同じ抽象的な文字を表す可能性があるが、異なる方法で表示される場合の弱い同等性の形式です。

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

Unicodeエンコーディングに関する重要なポイント

Unicodeエンコーディングを理解することは、特に異なるシステムや言語間の相互運用性の問題に対処する際に重要です。主なポイントは次のとおりです：

  • コードポイントと文字: Unicodeでは、各文字または記号に「コードポイント」として知られる数値が割り当てられます。

  • バイト表現: コードポイント（または文字）は、メモリ内で1つ以上のバイトで表されます。たとえば、LATIN-1文字（英語圏で一般的）は1バイトを使用して表されます。ただし、より多くの文字セットを持つ言語は、表現のためにより多くのバイトが必要です。

  • エンコーディング: この用語は、文字がバイトの系列に変換される方法を指します。UTF-8は一般的なエンコーディング標準で、ASCII文字は1バイトを使用して表され、他の文字には最大4バイトが使用されます。

  • データ処理: データを処理するシステムは、バイトストリームを文字に正しく変換するために使用されるエンコーディングを認識している必要があります。

  • 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 テンプレート

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

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

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

ファジング正規表現

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

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

参考文献

HackTricksをサポートする
PreviousUnicode InjectionNextUUID Insecurities

Last updated