XSS の防止に関する OWASP ガイドラインを読みました。ガイドラインは、ホワイトリストとエンコード出力を持つことのみを参照しているようです。ただし、これにより、いわゆるフリー テキスト フィールド (この投稿を作成するために書き込んでいるテキスト ボックスなど) の問題が未解決のままになります。
フリーテキストフィールドを受け入れるときにサーバー側で実行できるブラックリスト (望ましくない) 以外の予防策はありますか?
OWASP ガイドラインから、xss をデータベースに格納することを許可し、フロントエンドに表示されるたびにサニタイズする必要があるという印象を受けました。しかし、私はこれに少し不快です。それとも間違っていますか、もっと良い方法はありますか？
XSS は出力の問題です。すべての xss に対して機能するすべてのエンコーディングまたは入力検証関数を 1 つキャッチすることはできません。入力文字列を htmlentities に変換しても、アプリケーションはdom イベントや別のベクトルの xss に対して脆弱である可能性があります。これらのルールをすべて正確に保つことは困難です。コードを必ずテストしてください。SitewatchやSkipfishなどの無料の XSS スキャナーがあります。
HTML をデータベースに保存することは脆弱性ではありませんが、HTML を表示すると永続的な XSS になります。これは xss の最悪の形式です。エンコードされていないバージョンをデータベースに保存するのが一般的です。これにより、データの一貫性が保たれ、テキストの比較と一致が改善されます。MS-SQL の SQL インジェクションでは、クエリをスタックできるため、xss ペイロードをデータベースに導入できます。たとえば select...; insert into comments (post)values('<script>alert(xss)</script>')。 データベースを信頼しないでください。
私はOWASPガイドを率いており、ガイド2.0が2004/2005に書き戻されて以来、これに関する私の見解を成熟させてきました。
私の見解では、対処する必要のある2つのフェーズがあります。
入力の検証-可能な限り、データへのXSSベクトルの侵入を常に許可しないようにする必要があります。私はViews™を持っていますが、正直なところ、最善の策は、できる限り強く入力して長さを制限することです。ブール変数または整数変数をテキスト列として格納できるようにする意味はありません。残りのリスクは、テキストブロブに格納されているテキスト領域になります。これは、プレゼンテーション層をコーディングするときに明らかなはずです。
出力エンコーディング-元のガイドが書かれたとき（2002年）、私たちはBig 5を実行していましたが、それはもはや真実ではありません。コンテキストのエンコードを正しく出力する必要があるため、Ajaxに出力する場合は、JSONとJavaScriptの両方、およびHTMLを安全にする必要があります。
作業中のガイドの新しいバージョン、OWASPガイド2013があります。これが正しく更新されていることを確認します。
非常に有効な懸念があるため、プロジェクトの課題トラッカーに課題を記録してください。
ビッグ5を単純にエンコードする時代は、本当に終わりました。特に、HTMLが今後の主要なプレゼンテーション層になる可能性はかなり低いためです。
Andrew van der Stock、OWASPガイド2.0/2013ガイドリード。
xss をデータベースに格納することを許可し、フロントエンドに表示されるたびにサニタイズする必要があるという印象を受けました
それは正しいです。エンコーディングを行うために使用するアンチ XSS エンコーディング ライブラリ/関数は、ページ出力に追加されたときに危険なコードが HTML としてレンダリングされるのを防ぐことで、XSS の試みが機能するのを防ぎます。
ブラックリストを維持しないのとほぼ同じ理由で、保存する前に入力をスクラブしようとすべきではありません. 入力をスクラブしようとする場合は、自分が何をしているのかをよく理解してください。
したがって、ここで注意すべき点が 2 つあります。
ドメインに応じてデータが有効であることを確認するために、途中で入力の検証が行われます。これにより、一部の攻撃が阻止されますが、すべてではありません。
出力エンコーディングは、データが何らかの形で HTML または JavaScript として解析されないようにするために行われます。したがって、Rook で説明されているように、出力の問題です。HTML ページで XSS を直接回避する方法を説明する OWASP XSS 防止チート シートと、サニタイズされていないデータまたはエンコードされていないデータを JavaScript で読み書きすることによってトリガーされる XSS を回避する方法を理解するためのOWASP DOMベースの XSS 防止チート シートを参照してください。
Rook が述べたように、ドメインによって無効である場合を除き、途中でデータをエンコードまたはスクラブする誘惑に陥らないでください。出力の前に適切にエンコードする方法は実際にはありません。それは、エンコードしているコンテキストがわかっているときだからです。HTML属性、javascript文字列、HTML属性内のjavascript文字列などですか?
また、OWASP XSS 防止チート シートのルール #6 で述べられているように、一部の HTML ユーザーに OWASP AntiSamy や HTMLPurifier などのホワイト リスト ベースのエンジンを許可したい場合。