4

私はasp.netmvc学習サイトでJavaScriptインジェクションについて読んでいて、それは目を見張るものです。

JavaScriptを使用して奇妙なお尻のインジェクション攻撃を行う人については、私は気づかなかったし、考えたこともありませんでした。

しかし、それは私にいくつかの未回答の質問を残しました。

初め

いつhtml.encodeを使用しますか？そのユーザーまたは他のユーザーが送信した情報を表示する場合にのみ使用しますか？

それとも私はそれをすべてに使用しますか？ユーザーが送信するフォームがあると言うように、この情報はどのユーザーにも表示されません。引き続きhtml.encodeを使用する必要がありますか？

sayとHtml.TextBox（）にhtml.encodeタグを入れる方法がわからないようにするにはどうすればよいですか。

2番

何が起こるか私は私のサイトに豊富なhtmlエディタを持っていると言います。ユーザーはそれを使用して、物事を大胆にすることができます。次に、ラベルを介してユーザーに情報を表示したいと思います。Htmlをエンコードできません。それ以降、すべての太字などがレンダリングされなくなります。

それでも、ユーザーがJavascript攻撃を追加するのを阻止するのは何なのでしょうか？

だから私は何をしますか？正規表現を使用してすべてのタグを除外しますか？

第3

「AntiforgeryToken」と呼ばれる別のタグもありますが、これをいつ使用しますか？

ありがとう

編集

ほとんどの人が「ホワイトリスト」と「ブラックリスト」を使用すると言いますが、このリストをどのように記述して、受信する値と比較しますか（C＃の例がいいでしょう）。

4

4 に答える 4

2

ユーザーによって送信された表示中のデータには、HTMLエンコードを使用します。データベースに送信するときに使用する必要はありません。使用しないと、Simon'＆'Sonsのような奇妙なデータが得られます。本当に、ページに動的に書き込まれるコンテンツでそれを使用することに害はないと思います。

許可されたタグのリストを使用し、HTMLエディター用に他のすべてを破棄します。人々が言っ​​たように、ホワイトリストを使用してください。

3つ目は、クロスサイトリクエストフォージェリ攻撃を防ぐためのものです。これを使用して、ユーザーから「盗まれた」Cookieを使用してPOSTを実行できないようにします。そのため、投稿を受け入れる前に認証されたCookieが必要になる場合がありますが、悪意のあるユーザーが自分のサイトにアクセスしたときにそのCookieを取得し、サイトにフォームを送信して自分であると主張する可能性があります。

詳細については、こちらをご覧ください：http: //haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

使用方法：http： //blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

于 2009-07-21T07:50:58.677 に答える
2

良い質問！

  1. 最初の答えとして、私は以前に尋ねられた質問をここで見ることを検討します。答えが説明しているように、HTML Encodeを使用しても、すべてのXSS攻撃から完全に保護されるわけではありません。これを支援するには、 Microsoftから入手可能なMicrosoft Web Protection Library（特にAntiXSS）の使用を検討する必要があります。

  2. すでに述べたように、許可されたタグのリストを使用するのが最善の方法であり、他のタグは削除されます。

  3. AntiforgeryTokenトークンは、ページが投稿されたときにレンダリングされたフォームフィールドに対して検証されるCookieをユーザーに提供するため、リクエストフォージェリ（CSRF）を防ぐために機能します。これをすべてのフォームで使用できるわけではないことを私が認識している理由はありません。

于 2009-07-21T08:03:45.403 に答える
1

受け取った入力を常にホワイトリストと照合して検証します。ブラックリストを使用すると、エンコーディングの問題が発生する可能性があります。入力を検証するときは、常にホワイトリストを使用してください。

ユーザー入力を検証するためにクライアント側の検証に依存しないでください。クライアント側の検証は、ユーザーが正しいデータを入力するのに役立ちます。ただし、悪意のあるユーザーはこれを使用せず、クライアント側の検証をバイパスする可能性があります。クライアント側の検証は、セキュリティ修正と見なされるべきではありません。javascriptを使用して入力を検証することは使用しないでください。ご覧のとおり、JavaScriptはどのHTMLページでも非常に簡単に変更および変更できます。また、JavaScriptをブラウザで無効にすることもできます。したがって、コードビハインドファイルに追加のチェックを入れます。

さらに、データが最初に受け入れられたときだけでなく、毎回入力を検証します。たとえば、Cookieを設定する場合は、Cookieが同じ値であり、すべてのリクエストで正しいことを確認してください。悪意のあるユーザーは、セッション中にいつでも値を変更および変更する可能性があります。

于 2009-07-21T07:54:16.063 に答える
1

アプリケーションの設計上の考慮事項に基づいて実装できるセキュリティには、さまざまなレベルがあります。

私は次の基本的なルールに従います：

  1. すべての入力をサニタイズし、既知の悪意のあるセクション（たとえば、<script>リッチHTMLエディターのタグ）を削除します。この種の消毒には、正規表現ベースのパターンマッチングが一般的に使用されます。

  2. 許可された値のホワイトリストにないすべての入力を削除します。

  3. データベースに保存する前にHTMLをエンコードし、表示用に取得するときにデコードして戻します。

編集：@Phoenixはこのコンテキストでの検証について話しているので、これを追加すると思いました。私は前にこれを言いました、そして私は繰り返します：私はスクリプトベースの検証に反対していません。私は人々にそれを明示的に信頼しないように警告するだけです。一般的なデザインパターンは、スクリプトベースの検証を使用して基本的な基準を検証し、そのデータが送信されるときにサーバー側で厳密な検証を適用することです。

于 2009-07-21T07:59:58.673 に答える