AntiXss.HtmlEncodeとHttpUtility.HtmlEncodeの違いは何ですか？

Question

クロスサイトスクリプティングを回避するために、AntiXssライブラリを提案する質問がありました。 msdnブログを読んで、面白そうに聞こえましたが、HtmlEncodeを提供しているようです。 （） 方法。しかし、私はすでにHttpUtility.HtmlEncode（）を使用しています。

なぜHttpUtility.HtmlEncodeよりもAntiXss.HtmlEncodeを使用したいのですか？

実際、この質問をするのは私が初めてではありません。そして実際、Googleは some 回答、主に

• ブラックリスト方式ではなくホワイトリスト方式
• 0.1msのパフォーマンス改善

まあ、それは素晴らしいことですが、私にとってはどういう意味ですか？ 0.1msのパフォーマンスはあまり気にしませんし、既に持っている機能のために別のライブラリの依存関係をダウンロードして追加する気はありません。

AntiXss実装がHttpUtility実装では阻止できない攻撃を阻止する場合の例はありますか？

HttpUtilityの実装を引き続き使用すると、危険にさらされますか？ この「バグ」はどうですか？

Answer 1

あなたの質問に対する具体的な答えはありませんが、ホワイトリストとブラックリストのアプローチは<！> quot; nice <！> quot;だけではないことを指摘したいと思います。それは重要です。とても重要です。セキュリティに関しては、あらゆる小さなことが重要です。クロスサイトスクリプティングとクロスサイトリクエストフォージェリー 、サイトに機密データが表示されていない場合でも、ハッカーはjavascriptを挿入して別のサイトから機密データを取得することでサイトに感染する可能性があります。そのため、正しく実行することが重要です。

OWASPガイドラインでは、ホワイトリストアプローチの使用を指定しています。 PCIコンプライアンスガイドラインでは、コーディング標準でもこれを指定しています（OWASPガイドラインを参照しているため）。

また、新しいバージョンのAntiXssライブラリには、新しい関数.GetSafeHtmlFragment（）があります。これは、データベースにHTMLを保存し、ユーザーにHTMLとして表示する場合に便利です。

また、<！> quot; bug <！> quot;に関しては、適切にコーディングし、すべてのセキュリティガイドラインに従っている場合、パラメータ化されたストアドプロシージャを使用しているため、単一引用符が正しく処理されます。適切にコーディングしていない場合、既製のライブラリはあなたを完全に保護しません。 AntiXssライブラリは、知識の代わりではなく、使用するツールであることを意図しています。ライブラリを利用して適切な処理を行うと、優れたアーティストがいなくても優れた絵が完成する、本当に優れたペイントブラシが期待できます。

編集-追加

質問で尋ねられたように、anti xssがあなたを保護し、HttpUtilityが保護しない場所の例：

HttpUtility.HtmlEncodeおよびサーバー。 HtmlEncodeはクロスサイトスクリプティングを妨げません

ただし、著者によると。個人的にはテストしていません。

---

セキュリティガイドラインに従っているようですので、説明する必要はありませんが、経験の浅い開発者がこれを読んでいる場合に備えて、ホワイトリストこれがアプローチが重要です。

今日、HttpUtility.HtmlEncodeは、単に<および>に加えて、いくつかの他の<！> quot;潜在的に安全ではない<！> quot;既知の安全な（ホワイトリスト）コンテンツのみを許可することは、攻撃者があなたに投げかける可能性のあるすべての安全でない入力を考えるよりもはるかに簡単です（黒-listアプローチ）。

Answer 2

一方を他方よりも使用する理由については、Ant.SSフレームワークよりもAntiXSSライブラリが頻繁にリリースされることを考慮してください。DavidStrattonが言うように、 in '、誰かが1つを思いついたとき、AntiXSSライブラリはそれに対して防御するために更新されたリリースを取得する可能性が非常に高くなります。

Answer 3

Microsoft.Security.Application.AntiXss.HtmlEncodeメソッドとSystem.Web.HttpUtility.HtmlEncodeメソッドの違いは次のとおりです。

1. Anti-XSSは、包含の原則とも呼ばれるホワイトリスト技術を使用して、クロスサイトスクリプティング（XSS）攻撃から保護します。このアプローチは、最初に有効または許容可能な文字セットを定義し、このセット外のすべてのもの（無効な文字または潜在的な攻撃）をエンコードすることで機能します。 HttpUtilityおよびその名前空間の他のエンコード方法は、除外の原則を使用し、<！> lt;、<！> gt;、<！> amp;などの潜在的に危険と指定された特定の文字のみをエンコードします。および '文字。

2. Anti-XSS Libraryの白い（または安全な）文字のリストは、12を超える言語（ギリシャ語とコプト語、キリル文字、キリル文字サプリメント、アルメニア語、ヘブライ語、アラビア語、シリア語、アラビア語サプリメント、Thaana、NKoおよび詳細）

3. Anti-XSSライブラリは、XSS攻撃を軽減するために特別に設計されていますが、ASP.NET出力がHTMLを壊さないようにするためにAntiXss.HtmlEncode()エンコーディングメソッドが作成されます。

4. パフォーマンス-HttpUtility.HtmlEncode()と<=>の間の平均デルタは、トランザクションごとに+0.1ミリ秒です。

5. Anti-XSSバージョン3.0は、開発者がXSS検証とパフォーマンステストの両方を実行できるテストハーネスを提供します。

Answer 4

ほとんどのXSS脆弱性（実際、あらゆるタイプの脆弱性）は、既存のセキュリティが<！> quot; expect <！> quot;でなかったという事実に純粋に基づいています。特定のことが起こる。ホワイトリストのみのアプローチは、デフォルトでこれらのシナリオを処理するのに適しています。

Answer 5

マイクロソフトのWindows Liveサイトでは、ホワイトリストアプローチを使用しています。私たちがまだ考えていないセキュリティ攻撃がいくつもあると確信しているので、私は偏執的なアプローチにもっと慣れています。ブラックリストがホワイトリストにはない脆弱性を公開しているケースもあると思いますが、詳細はお伝えできませんでした。