51

クロス サイト スクリプティングを回避するために AntiXss ライブラリを提案する回答を含む質問に出くわしました。msdn blogを読んで興味深いことに、HtmlEncode() メソッドを提供するだけのようです。しかし、私はすでに HttpUtility.HtmlEncode() を使用しています。

HttpUtility.HtmlEncode ではなく AntiXss.HtmlEncode を使用する必要があるのはなぜですか?

実際、この質問をしたのは私が初めてではありません。実際、Google は主にいくつかの 回答を提示しています。

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

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

HttpUtility 実装では防げない攻撃を AntiXss 実装で防げる例はありますか?

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

4

5 に答える 5

35

あなたの質問に具体的に答えることはできませんが、ホワイトリストとブラックリストのアプローチは「いい」だけではないことを指摘したいと思います。それは重要です。非常に重要です。セキュリティに関しては、あらゆる小さなことが重要です。クロスサイト スクリプティングとクロスサイト リクエスト フォージェリを使用すると、サイトに機密データが表示されていなくても、ハッカーが JavaScript を挿入してサイトに感染し、それを使用して別のサイトから機密データを取得する可能性があることに注意してください。したがって、正しく行うことが重要です。

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

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

また、「バグ」に関しては、適切にコーディングし、すべてのセキュリティ ガイドラインに従っている場合は、パラメーター化されたストアド プロシージャを使用しているため、単一引用符は正しく処理されます。シェルフ ライブラリはあなたを完全に保護します。AntiXss ライブラリは、知識に代わるものではなく、使用するツールであることを意図しています。ライブラリに頼って適切に処理してもらうことは、優れたアーティストがいなくても、本当に優れた絵筆が優れた絵画を生み出すことを期待することになります。

編集 - 追加

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

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

とはいえ、著者によると。私は個人的にそれをテストしていません。

あなたはセキュリティ ガイドラインに準拠しているように聞こえるので、これは私があなたに言う必要はないかもしれませんが、経験の浅い開発者がこれを読んでいる場合に備えて、ホワイトリスト アプローチが重要であると私が言う理由これは。

現在、今日、HttpUtility.HtmlEncode は、 と を削除/エンコードするだけで、そこにあるすべての攻撃を首尾よくブロックすることが<でき>ます。既知の安全な (ホワイト リスト) コンテンツは、攻撃者が投げかける可能性のある危険な入力をすべて考えようとする (ブラック リスト アプローチ) よりもはるかに簡単です。

于 2009-10-22T17:58:53.980 に答える
12

どちらか一方を使用する理由については、AntiXSS ライブラリが ASP.NET フレームワークよりも頻繁にリリースされることを考慮してください。なぜなら、David Stratton が言うように、「誰かが常に新しい侵入方法を考えようとしているからです」誰かがそれを思いついた場合、AntiXSS ライブラリは、それを防御するために更新されたリリースを取得する可能性がはるかに高くなります。

于 2009-10-23T13:50:34.267 に答える
10

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

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

  2. アンチ XSS ライブラリの白い (または安全な) 文字のリストは、12 を超える言語 (ギリシャ語とコプト語、キリル語、キリル語補足、アルメニア語、ヘブライ語、アラビア語、シリア語、アラビア語補足、Thaana、NKo など) をサポートしています。

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

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

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

于 2011-07-29T06:41:04.637 に答える
5

ほとんどの XSS 脆弱性 (実際にはあらゆる種類の脆弱性) は、既存のセキュリティが特定のことが起こることを「予期」していなかったという事実に純粋に基づいています。ホワイトリストのみのアプローチは、デフォルトでこれらのシナリオを処理するのにより適しています。

于 2009-10-23T14:01:07.553 に答える
3

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

于 2009-10-22T18:01:15.497 に答える