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 response.redirect to achieve this, with the redirection URL being dynamically generated in the code behind on the postback method of various buttons.

This is fine in 95% of the cases, however I am noticing that sometimes the URL is mangled horribly.

In one case, the url is URLEncoded, as one of the parameters sometimes contains an ampersand, however the redirect is ignoring this and redirecting to a non-encoded version.

i.e. "page.aspx?qs=first%26second&qs=2&qs=3" is being redirected to "page.aspx?qs=first&second&qs=2&qs=3"

the other case that happens is that the response is completely stripped of ampersands, leading to frequent crashes.

i.e. "page.aspx?qs=1&qs=2&qs=3" is being redirected to "page.aspx?qs=1qs=2qs=3"

Does anyone have any ideas why either of these scenarios might happen?

RESOLVED

Sorry, this was due to my own idiocy, in redirecting from admin to non-admin (don't ask), and not putting the &s back in or url encoding again on a couple of pages.

(facepalm)

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?