いくつかの API を呼び出す Web アプリを PHP で作成しています。これらの API のコンテンツは信頼できないため、ユーザーに表示する前に XSS でフィルタリングしたいと考えています。XSS フィルターを実行するのに適切な MVC レイヤーはどれですか?
3 に答える
プレゼンテーション層。正確にインスタンスを表示します。テンプレートに値を割り当てる前。
XSSは何かであり、応答の形式に関連付けられています。たとえば、ビューがJSON応答を作成している場合、HTML応答と同じ潜在的な弱点はありません。これは、HTTPヘッダーのみを応答として送信する前に行うチェックとは完全に異なります。
PSビューはテンプレートではありません。
Stack Overflow でいくつかの同様の質問を見つけました。Quentinによる回答が、この質問に回答する最良の方法のようです。彼の答えを次のように要約します。
データは、使用する直前にサニタイズする必要があります。
API から信頼できないデータを取得してビューに表示しているので、そこで XSS 用にフィルター処理します。
答えは少し複雑で、好みにもよります。フィルタリングの最初のステップは、入力の検証です。モデルに値を割り当てる前にコントローラーで入力検証を行うか、モデル フィールドに注釈を付けて検証ルールをモデル自体に配置し、モデル自体を検証させるかを選択できます。
入力の検証とは、ドメインに従ってデータが有効であることを確認することです。ユーザー名フィールドの場合、おそらくその中に script-tag は必要ありません。ただし、script-tag が攻撃でなくても完全に有効なデータである場合もあります。そのような例の 1 つが、まさにこのサイト、stackoverflow です。コメントまたは質問フィールドでは、ユーザー データとして有効であるため、スクリプト タグを許可する必要があります。ただし、スクリプトがコードとして解釈されず、データのままであることを確認する必要があります。これにより、答えの 2 番目の部分であるエンコードに進みます。
エンコードするときは、コンテキストに応じてエンコードする必要があります。次のように JavaScript 変数内で出力を行う場合:
<script> var a = 'INPUT_HERE'</script>
HTML タグ間で出力する場合とは異なるエンコーディングを使用する必要があります。
<h1>INPUT_HERE</h1>
またはhtml属性内またはCSS内....
OWASP Abridged XSS Prevention Cheat sheet を強くお勧めします: https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet
これが意味することは、データを出力する場所に応じて環境設定を変える必要があり、同じデータを同じビュー内または同じテンプレート内の異なる場所に出力する可能性があるということです。
したがって、データを HTML に入れる場所でエンコーディングを行う必要があります。これは、どのエンコーディングを使用するのが正しいかを知っているからです。