11

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

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

4 に答える 4

40

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

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

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

于 2010-02-24T14:23:26.483 に答える
15

XSSでJeffWilliamsと一緒にOWASPポッドキャスト67を聴いてください。彼は、保管前にサニタイズやエンコードを行わないことについて話します。主な理由は、（いつ）ライブラリが新しい脆弱性に対応して進化した場合、データが古いバージョンに戻されてしまうことです。もちろん、これは、エントリポイントでホワイトリストに対して入力を実行し、許容範囲外のものを拒否することを妨げるものではありません。

于 2010-05-25T21:16:44.830 に答える
3
  • 両方
  • あなたがそれを変更する予定がある場合のみ、私は個人的にはしません
  • AntiXss クラス ( として呼び出されるためAntiXss.GetSafeHtmlFragment())
于 2010-01-13T22:55:32.033 に答える
-1

ページディレクティブでパラメータValidateRequest="true"を使用できます。このようにして、すべてのリクエストデータが検証され、検証の問題がある場合はいつでもエラーをキャッチできます。また、XSSだけでなくSQLインジェクションスレッドなども防止します。

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

他のクラスや追加の消毒剤メソッドを使用する必要はありません。

于 2010-01-13T23:06:37.877 に答える