security - XSS 攻撃ベクトル

Question

ページに戻ってくるテキストフィールドからのサニタイズされていない入力以外に、Web サイトで一般的な XSS ベクトルは何ですか? Cookie 内の csrf トークンへの悪意のあるアクセスを防止しようとしています。テキスト入力から安全でない文字をエスケープしています (おそらく、データベースの挿入または UI への出力の前に、Java サーブレットにもそれを追加することになります)。サイトに入る XSS を探すには、他にどこを探すべきですか?

Answer 1

私が質問を正しく理解していれば、UI の入力フィールドからのユーザー入力をエンコードすることで、反映および保存された XSS のいくつかの形式を軽減しました。

次の点に注意してください。

• すべてのユーザー入力が UI 入力フィールドから行われるわけではありません。Cookie とリクエスト ヘッダーもユーザー入力の例です。もちろん、隠しフィールドや json/xml/その他の種類のパラメーターも同様です。アプリケーションがファイルを処理したり、http 以外の外部要求を受け取ったりする場合、それらもユーザー入力です。データベースのフィールドでさえ、ユーザー入力として処理し、ページへの書き込み時にエンコードするのが最善です。特に、他のコンポーネントもデータベースに書き込む場合はそうです。
• アプリケーションではすでにそうなっているかもしれませんが、この回答をより包括的にするために、XSS は出力の問題であり、ユーザー入力がどこから来るかに関係なく、ほとんどの場合、解決策は出力エンコーディングです (入力の検証/サニタイズではありません)。特にブラックリストではありません）。ただし、これには注意深い例外があるかもしれません。もちろん、入力の検証は適切な出力エンコーディングを適切に補完します。
• エンコーディング方法は、データが書き込まれるコンテキストに従って選択する必要があります (つまり、javascript ブロックまたはプレーン html に書き込む場合は、異なるエンコーディングが必要です。また、javascript ブロックは script タグ内だけでなく、たとえばイベント属性内にもあることに注意してください)。 onclick など）。
• DOM XSS は完全にクライアント上にあり、Javascript で軽減する必要があります。以下の関連する OWASP ガイドを参照してください。

一般的なOWASP XSS ページは非常に便利です。また、いくつかのガイドもあります。

• 保存および反映される XSS 防止チート シート
• DOM XSS 防止チートシート
• Reflected、stored、およびDOM XSSのテスト。