Response.Redirect occasionally ignores URL encoding

Question

In the website I\'m currently building we need a large number of dynamic redirects, in order to maintain flow through parts of the site.

I\'m currently using respons

Answer 1

I would say that the reason this is happening is due to how the Response.Redirect method works internally.

Internally, the Redirect method will inspect the string URL parameter and, if it deems necessary, perform some encoding on the string URL parameter prior to actually performing the redirect.

This can be evidenced by looking at the disassembly of the Response.Redirect method within Reflector. Amongst other things, the Redirect method performs:

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

Looking into each of these functions, there are calls to other functions such as:

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)

Each of these functions attempts to encode (or transform) the provided string URL parameter in some way.

According to this page: Response.Redirect and encoded URIs (and others linked from here), there can be some issues with this encoding that is performed, depending upon the input string.

It would appear that the best way of avoiding any encoding issues that may arise when allowing the Redirect method to do it's own encoding is to explicitly encode the string URL parameter yourself prior to passing it to the Redirect method.

From the Response.Redirect MSDN Article:

Always validate and encode the URL that is passed to Response.Redirect to protect against cross-site scripting attacks. For information about how to remove harmful characters from strings, see Removing Harmful Characters from User Input.

Note that there has also previously been bugs in the Response.Redirect methods encoding when not using a fully qualified URL. Is it possible you are using a version of the .NET framework that is vulnerable to this issue?