正規化と出力エンコーディング
私はOWASPのSecure Coding Practices Checklistを読んでおり、「Input Validation」セクションの下に次の項目があります。
潜在的に危険な文字（
<>"'%()&+\\'\"）を入力として許可する必要がある場合は、必ず出力エンコーディングなどの追加のコントロールを実装してください。正規化を利用して、二重エンコーディングや他の形式の難読化攻撃に対処します。
- 「出力エンコーディング」とは何ですか？誰かが検証ルーチンがそれをどのように利用できるかの具体的な例を提供できますか？
- 「ダブルエンコーディング」とは何ですか。なぜ「難読化攻撃」なのですか？
- 「正規化」とは何ですか？なぜそれが二重エンコーディングを防ぐのですか？
3番目のものについては、OWASPによって提供されるcanonicalizationのやや曖昧な定義が見つかりました：さまざまなデータエンコーディングを単一の単純な形式に削減しかし、その定義ではありません彼らが話していることを理解するのに本当に役立ちます。
私はJavaおよびPythonで得意ですが、任意の言語の例に従うことができます。ここで彼らが話していることを視覚化しようとしています。 「木々の森」を見るのに苦労しています。よろしくお願いします。
正規化を説明する最良の方法は、それがCanonに由来することを覚えておくことです。彼らが話しているのは、信頼できないデータを明確な表現としてフォーマットし、ソフトウェアプロセスによって誤って表現されることのないようにすることです。
最初のステップは、入力を受け取り、どこかに保存することです。入力は、ASCII、UTF-8、UTF-16、または他の任意の数のエンコードスキームとしてエンコードされる場合があります。ソフトウェアはこれを検出し、データを適切に変換して単一の形式で保存する必要があります。現在は単一の明確な形式になっているため、そのように解釈すると正しいことがわかっています。つまり、Canonです。これにより、後でデータを出力する際の絶対的な確実性が可能になります。
たとえば、_'; DROP TABLE users; --_をフォームに挿入すると、アプリの記述が不十分な場合にSQLインジェクションが発生する可能性があります。ただし、正規化では、データはデータのみであり、SQLクエリの一部として表すことはできません。実際には、SQLの正規化形式はパラメーター化されたクエリです。さらに、有効なコードポイントのみが保存されるように、テキストエンコーディングを単一の既知のタイプに変換するための手順を実行する必要があります。これを行わないと、コードポイントが別の文字として誤って解釈される可能性があります。
HTMLへの出力についても同様の例を示します。データベースに<script>alert('xss!');</script>が含まれている場合、単純なアプリはそれを直接ページに書き込み、セキュリティの問題を引き起こす可能性があります。ただし、出力エンコーディングの形式で適切な正規化を行うと、<script>alert('xss!');</script>が得られますが、これはブラウザーが誤って解釈することはありません。
ダブルエンコーディングは、特定のパーサーをだますために使用されるトリックです。攻撃者は、使用しているエンコーディングを特定し、この形式でデータを事前にエンコードします。パーサーは、データがCanonであると誤って想定し、そのように処理します。その結果、データが誤って処理され、エクスプロイトが発生します。これは、攻撃者がエクスプロイトデータを難読化して、エンコーダーが不正な文字を認識しないようにするため、難読化攻撃です。