XSS脆弱性を取り除くための最良のアプローチ
私はWebobjectsアプリケーションを開発していて、アプリケーションがURLを介してXSSに対して脆弱であることがわかりましたが、<script>alert("hi")</script>などの悪意のある入力がフォームフィールドに入力された場合はそうではありません。
したがって、私は現在、この問題を解決するためにApache WebサーバーでURL書き換えの手法を採用しています。
次のJavaScriptキーワードを処理しました：srconloadonmouseoveronkeypressonfocusalert
XSSについてはよく知りません。
ここの専門家から知りたいのですが、フォームフィールドへの入力が脆弱性を示さない場合、これはXSSを解決する正しいアプローチですか？
提案してください。
いいえ。 Apache WebサーバーでURLの書き換えを行ってXSSを修正しようとしないでください。結果はせいぜい壊れやすいので、それを実行するのに良い方法ではありません。特に、現在のアプローチに固執している場合でも、XSSを悪用する卑劣な方法が依然として存在する可能性があります。
代わりに、WebアプリケーションにXSSホールがある場合は、darn Webアプリケーションを修正します。これはアプリケーションのセキュリティ問題です。アプリケーションを修正して修正する必要があります。外部からパッチを当てようとすると、ふるいのように漏洩する可能性があります。
追伸キーワードのリストが不十分です。ブラックリストを作成しました。他のブラックリストと同様に、ブラックリストは必然的に不完全です。いくつか欠落しています（*咳* onerror *咳*）。より完全なリストを提供しようとするつもりはありません。アプローチが根本的に壊れていて、アプローチに固執して属性のリストをフィルターに拡張しようとするのではなく、現在のアプローチを完全に破棄する必要があるためです。ソースで問題を修正します。
OWASPから良いリソースがあります： XSS（クロスサイトスクリプティング）防止のチートシート
基本的に、ホワイトリストアプローチを使用してすべての入力データを検証する必要があります（現時点では無効なパターンではなく、有効なパターンを定義します）。また、特定のコンテキスト（HTML、JavaScript、HTML属性）に適したエンコードスキームを使用して、出力のすべてのデータをエンコードする必要があります。 ）。
正しいエンコーディングは非常に困難であり、自分で行うべきではありません。代わりに、 Microsoft AntiXSS Library または OWASP ESAPI のようなライブラリを使用する必要があります。
ModSecurity （または他のWAF）を正しい検出ルール（つまり ModSecurity Core Rule Set ）で使用することもできますが、これが唯一のソリューションではないことに注意してください。