2

初めての AntiXSS 4 ユーザーはこちら。アプリケーションをより安全にするために、Microsoft.Security.Application.Encoder.UrlEncodeを QueryString パラメーターで 使用し、 Microsoft.Security.Application.Encoder.HtmlEncodeをフォーム フィールドに入力されたパラメーターで使用しました。

私には複数の回答があり、それらすべてに回答していただければ幸いです (一度に、または同じ人である必要はありません - どんな回答でも非常に役に立ちます)。

私の最初の質問は、これらのメソッドを適切に使用しているか (つまり、適切な状況に適切な AntiXSS メソッドを使用しているか) ということです。

私の2 番目の質問は、何かをエンコードしたら、それがデコードされた場合です。HttpUtilityクラスがエンコードとデコードの両方の方法を提供することを知っているので、私は混乱しています。なぜ同じことが AntiXSS で行われないのですか? これが役に立てば、エンコードしたパラメーターは、アプリケーション内でテキスト以外のものとして扱われることはありません。

私の3 番目の質問は 3 番目の質問に関連していますが、重要なので強調したいと思います (そして、おそらく全体的な混乱の原因です)。.NET フレームワークは QueryStrings などを自動的にデコードするため、明示的なデコード メソッドは必要ないと聞いたことがあります。もしそうなら、それが元に戻されるのであれば、そもそも HTML エンコーディングのポイントは何でしょう。ただ...安全ではないようですか？特に、前述のようにHttpUtilityクラスがデコードを提供しているため、何が欠けていますか。

最後の質問ですが、AntiXSS は SQL インジェクションに対してまったく役に立ちますか、それとも XSS 攻撃を防御するだけなのでしょうか?

4

1 に答える 1

2

  1. 正しく使用しているかどうかはわかりません。ページにリンクとして出力されるクエリ文字列を作成するときにUrlEncodeを使用する場合は、そうです。値として何かを書き出すときにHtmlEncodingを使用している場合は、その通りです（HTML属性を介して設定されている場合は、HtmlAttributeEncodeを使用する必要がありますが、ほとんど同じです）。

  2. .NETデコーダーはAntiXSSのエンコードされた値で動作するので、私がそれらをニヤリと書き直す意味はありませんでした

  3. エンコードのポイントは、出力時に行うことです。したがって、たとえば、ユーザーがフォームにinput window.alert（'Numpty！）を持っていて、その入力を生で出力に入れると、javascriptが実行されます。最初にエンコードすると、<が＆lt;になります。等々。

  4. いいえ、SQLインジェクションはまったく別の問題です。

于 2011-08-18T06:16:50.270 に答える