DB に保存する前、またはレンダリングする前に HTML をサニタイズしますか?(ASP.NET の AntiXSS ライブラリ)

Question

ユーザーがデータベースに保存され、Web ページ上に表示される HTML を追加できるエディターを持っています。これは信頼できない入力であるため、使用する予定です Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment HTMLをサニタイズします。

• データベースに保存する前、または信頼できない入力を Web ページにレンダリングする前にサンティ化する必要がありますか?
• DLL だけではなく、AntiXSS ソース コードをプロジェクトに含めることに利点はありますか?（ホワイトリストをカスタマイズできるかも？）
• GetSafeHtmlFragment を実際に実装するにはどのクラス ファイルを調べればよいですか

Answer 1

2 つの理由から、選択した回答に同意しません

1. エンコードされたデータを保存した場合は、保存する前にエンコーダーを選択する必要があります。何かを HTML として保存していて、それを別の形式 (たとえば、JSON 応答や XML ドキュメントの一部として) でプッシュしたい場合はどうなるでしょうか?これで、HTML エンコード形式が完成しました。デコードしてから、正しい形式でエンコードする必要があります。
2. エンコーダーにバグが発見され、新しいバージョンがリリースされたらどうなるでしょうか?ここで、出力時にエンコードしていないため、すべての古いデータには正しくエンコードされていないものが含まれている可能性があります。再度エンコードすることはできますが、二重エンコードの問題が発生し、正しくフィルタリングするのが困難になる可能性があります。

通常、出力時点でエンコードし、データ ストアからのデータをデフォルトで信頼できないものとして扱います。結局のところ、誰かがデータベースを直接または SQL インジェクション経由で編集できたらどうなるでしょうか?

Answer 2

XSSのジェフ・ウィリアムス OWASPポッドキャスト67を持っています>。彼は、保存前消毒やエンコーディングない語ります。主な理由は、もし（）ライブラリは、あなたのデータは古いバージョンに戻って立ち往生されようとしている新たな脆弱性に対応して進化しています。もちろんこれは、エントリポイントでホワイトリストに対する任意の入力を実行し、許容範囲外のものを拒絶するからあなたを停止しません。

Answer 3

• 両方
• それを変更する予定がある場合のみですが、私は個人的には変更しません
• AntiXss クラス (次のように呼ばれているため) AntiXss.GetSafeHtmlFragment())

Answer 4

あなたは、pageディレクティブのパラメータののvalidateRequest = "true" をを使用することができます。このように、全ての要求データが検証され、検証問題がある場合は、常にエラーをキャッチすることができます。また、SQLインジェクションのスレッドなどを防ぐだけでなく、可能XSSます。

は、数値データを使用すると、Int32.TryParse（）または整数オーバーフローやデータ型の誤用を検証することができTryParseファミリーの他の（Byte.TryParse Int16.TryParse ...）

他のクラスまたは追加の消毒方法を使用する必要はありませんします。