XSSの攻撃ベクトル

Question

テキストフィールドからの非正規化された入力以外にも、Webサイトに共通のXSSベクトルは何ですか？クッキー内のcsrfトークンへの悪意のあるアクセスを防止しようとしています。私は安全でない文字をテキスト入力から逃げ出しています（データベースの挿入やUIへの印刷の前にJavaサーブレットで追加することになるでしょう）。 XSSがサイトに入るのをどこで調べるべきですか？

Answer 1

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

あなたはいくつかの点に注意してください。

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

一般的なOWASP XSS pageは非常に便利です。 reflected、storedとDOM XSSのため

• Stored and Reflected XSS prevention cheat sheet
• DOM XSS prevention cheat sheet
• テスト： は、彼らはまた、いくつかのガイドを持っています。