CAT.NETは、以下がASP.NETの真の脆弱性であるということで正しいですか、それとも誤検知ですか?
var myInt = Int32.Parse(txtUserInput.Text);
Response.Redirect(string.Format("myPage.aspx?myId={0}", myInt);
CAT.NETは、myIntのエンコードによる修正が必要なリダイレクトの脆弱性としてこれを報告しています。
CAT.NETは、以下がASP.NETの真の脆弱性であるということで正しいですか、それとも誤検知ですか?
var myInt = Int32.Parse(txtUserInput.Text);
Response.Redirect(string.Format("myPage.aspx?myId={0}", myInt);
CAT.NETは、myIntのエンコードによる修正が必要なリダイレクトの脆弱性としてこれを報告しています。
私はそうは思わない、それは例外を引き起こす可能性があるので、TryParseがより良いアプローチかもしれない。ユーザー入力を受け取り、それに基づいてリダイレクトしているので、それはただ叫んでいます。少し攻撃的すぎる可能性がありますが、それほど悪くはありません。
私はそれを危険とは言いませんが、それは私が自分でそれを書く方法ではありません
int myInt;
if(Int32.TryParse(txtUserInput.Text,out myInt)){
Response.Redirect(string.Format("myPage.aspx?myId={0}", myInt);
}
悪いユーザー入力が原因で解析が失敗し、明示的にintを入力している場合でも例外がスローされないため、私の考えではよりクリーンです。
エラー処理コードは、最後にelseステートメントにバンドルできます。
このコードの結果として悪用可能な脆弱性はありません。脆弱性は、URLの作成方法ではなく、myPage.aspxがmyIdの値を使用して行うことの結果です。クエリ文字列に必要なものを使用して、誰でも簡単にmyPage.aspxに直接アクセスできます。
ただし、これら2行の間にコードから何も残していないと仮定すると、これは悪い習慣です。txtUserInput.Textに数字のみが含まれており、許容値の範囲内にあることを確認する必要があります。
エクスプロイトは、投稿先のページによるユーザー提供データの不適切な解析が原因で発生します。URLの不適切な生成ではありません。フォームに入力されたものが原因でWebサイトが壊れたURLを書き込まないようにすることをお勧めしますが、フロントエンドでの入力検証はセキュリティとは無関係です。重要なのは、入力を受け入れるコードがそれをどのように処理するかです。これは、任意の投稿またはクエリ文字列を偽造できるためです。