3

私が現在構築しているWebサイトでは、サイトの一部を通過するフローを維持するために、多数の動的リダイレクトが必要です。

私は現在、これを実現するためにresponse.redirectを使用しています。リダイレクトURLは、さまざまなボタンのpostbackメソッドのコードビハインドで動的に生成されます。

これは95％のケースで問題ありませんが、URLがひどく壊れていることがあることに気づいています。

あるケースでは、パラメータの1つにアンパサンドが含まれていることがあるため、URLはURLEncodedですが、リダイレクトはこれを無視し、エンコードされていないバージョンにリダイレクトします。

つまり、「page.aspx？qs = first％26second＆qs = 2＆qs = 3」は、「page.aspx？qs = first＆second＆qs = 2＆qs=3」にリダイレクトされます。

発生するもう1つのケースは、応答からアンパサンドが完全に取り除かれ、頻繁にクラッシュすることです。

つまり、「page.aspx？qs = 1＆qs = 2＆qs =3」は「page.aspx？qs = 1qs = 2qs=3」にリダイレクトされます

これらのシナリオのいずれかが発生する可能性がある理由を誰かが知っていますか？

解決済み

申し訳ありませんが、これは私自身の愚かさによるもので、管理者から非管理者にリダイレクトし（尋ねないでください）、数ページで＆sを元に戻さなかったりURLエンコードを再度行ったりしませんでした。

（facepalm）

4

1 に答える 1

6

これが発生している理由は、Response.Redirectメソッドが内部でどのように機能するかによると言えます。

内部的には、Redirectメソッドは文字列URLパラメーターを検査し、必要であると判断した場合は、実際にリダイレクトを実行する前に、文字列URLパラメーターでエンコードを実行します。

Response.Redirectこれは、 Reflector内のメソッドの分解を調べることで証明できます。特に、このRedirectメソッドは次のことを実行します。

url = this.ApplyRedirectQueryStringIfRequired(url);
url = this.ApplyAppPathModifier(url);
url = this.ConvertToFullyQualifiedRedirectUrlIfRequired(url);
url = this.UrlEncodeRedirect(url);

これらの各関数を調べると、次のような他の関数への呼び出しがあります。

internal static string UrlEncodeNonAscii(string str, Encoding e)
internal static string UrlEncodeSpaces(string str)
private static byte[] UrlEncodeBytesToBytesInternalNonAscii(byte[] bytes, int offset, int count, bool alwaysCreateReturnValue)

これらの各関数は、提供された文字列URLパラメーターを何らかの方法でエンコード（または変換）しようとします。

このページによると：Response.RedirectおよびエンコードされたURI（およびここからリンクされている他のURI）、入力文字列によっては、実行されるこのエンコードにいくつかの問題がある可能性があります。

メソッドに独自のエンコードを許可するときに発生する可能性のあるエンコードの問題を回避する最善の方法は、Redirectメソッドに渡す前に文字列URLパラメーターを自分で明示的にエンコードすることRedirectです。

Response.RedirectMSDNの記事から：

クロスサイトスクリプティング攻撃から保護するために、Response.Redirectに渡されるURLを常に検証してエンコードします。文字列から有害な文字を削除する方法については、「ユーザー入力からの有害な文字の削除」を参照してください。

完全修飾URLを使用しない場合のResponse.Redirectメソッドのエンコードにも以前はバグがあったことに注意してください。この問題に対して脆弱なバージョンの.NETFrameworkを使用している可能性はありますか？

于 2009-09-24T15:25:31.817 に答える