4

XSS 攻撃に対して 100% 効果的なソリューションは存在しないという事実を読みました (そして受け入れようとしています)。私たちが望むことができる最善の方法は、「ほとんどの」XSS 攻撃手段を阻止することであり、その後、おそらく適切な復旧および/または法的な計画を立てることです。最近、許容できるリスクと許容できないリスクを判断するための適切なフレームワークを見つけるのに苦労しています。

Mike Brind によるこの記事を読んだ後 (非常に良い記事です):

http://www.mikesdotnetting.com/Article/159/WebMatrix-Protecting-Your-Web-Pages-Site

ユーザー入力を未検証にする必要がある場合、HTMLサニタイザーを使用すると、XSS攻撃の経路を減らすのにも非常に効果的であることがわかります。

ですが、私の場合は逆です。Web インターフェイスを備えた (非常に限定的な) CMS を使用しています。ユーザー入力 (URL エンコード後) は JSON ファイルに保存され、表示可能なページで取得 (デコード) されます。ここで XSS 攻撃を阻止するための私の主な方法は、コンテンツを変更するには数少ない登録メンバーの 1 人になる必要があるということです。登録ユーザー、IP アドレス、およびタイムスタンプをログに記録することで、この脅威はほとんど軽減されると思いますが、以前のステートメントに加えて、asp.net の既定の要求バリデーターによって生成された YSOD をキャッチする try/catch ステートメントを使用したいと考えています。言及された方法。

私の質問は次のとおりです。このバリデーターをどの程度信頼できますか? タグが検出されることはわかっています (この部分的な CMS は、論理的に言えば、タグを受け入れるように設定されていないため、タグが検出された場合にエラーがスローされても問題ありません)。しかし、この生まれつきのバリデーターは他に何を (もしあれば) 検出するのでしょうか?

XSS は山かっこ (または完全なタグ) に触れなくても実装できることを知っています。html ソースを保存、編集し、クライアント コンピューターから実行することができるのは、単純にエクストラを追加するだけだからです。 「onload='BS XSS ATTACK'」をランダムなタグに追加します。

このバリデーターをアンチ XSS 計画の一部として使用したい場合に、このバリデーターがどれだけ信頼できるかを知りたいです (もちろん、try/catch を使用するため、ユーザーには YSOD が表示されません)。このバリデーターはかなりまともですが、完全ではありませんか? それとも、XSS を知るのに十分な知識を持っている人なら誰でも、この検証が実際には問題にならないという十分な知識を持っているという「最良の推測」ですか?

- - - - - - - - - - - -編集 - - - - - - - - - - - - - -----

このサイトで...: http://msdn.microsoft.com/en-us/library/hh882339(v=vs.100).aspx

...この例は Web ページで見つかりました。

var userComment = Request.Form["userInput"]; // Validated, throws error if input includes markup

Request.Unvalidated("userInput"); // Validation bypassed
Request.Unvalidated().Form["userInput"]; // Validation bypassed

Request.QueryString["userPreference"]; // Validated
Request.Unvalidated().QueryString["userPreference"]; // Validation bypassed;

コメントによると、「//検証済み、入力にマークアップが含まれている場合はエラーがスローされます」文字列にマークアップと見なされるものが含まれている場合、バリデーターはエラーをスローすると思います。ここで、(私にとっての) 疑問は次のようになります: マークアップとは何ですか? テストを通じて、単一の山かっこはエラーをスローしないことがわかりましたが、何か (これまでにテストしたもの) がその山かっこの後に続く場合は、次のようになります。

"<l"

エラーになりそうです。ただし、それよりも多くのチェックを行っていると確信しています。リクエストバリデーターの目には、何がマークアップと見なされ、何がマークアップとして認められないかを確認したいと思います。

4

1 に答える 1

2

ASP.NET要求の検証はかなり信頼できると思いますが、それだけに頼るべきではありません。一部のプロジェクトでは、セキュリティの追加レイヤーを提供するために有効のままにしておきます。一般に、自分で作成するよりも、広くテスト/利用されているソリューションを使用することをお勧めします。「YSOD」（またはカスタムエラーページ）がクライアントで問題になる場合は、通常、ページの.NET要求検証機能を無効にします。

そうしたら、入力がサニタイズされていることを注意深く確認しますが、さらに重要なのは、出力がエンコードされていることです。したがって、ユーザーが入力した（またはWebサービスなど-サードパーティからのコンテンツ）コンテンツをユーザーにプッシュする場所では、Server.HtmlEncode（）にラップされます。このアプローチは、ここ数年かなりうまく機能しています。

あなたがMicrosoftのドキュメントに提供したリンクはかなり良いです。マークアップと見なされるもの（またはマークアップと見なされるもの）に関する質問に答えるには、ハッカーの帽子をかぶって、OWASPXSS回避チートシートを確認してください。

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#HTML_entities

于 2013-02-21T15:20:15.087 に答える