ASP.NET MVC "Potentially dangerous Request.Path" with valid URL

Question

On my production ASP.NET MVC 3 site, I've been noticing the occasional "A potentially dangerous Request.Path value was detected from the client (%)." unhandled exception in the Windows application log.

While these can be perfectly valid under regular site usage (ie/ random web bots), a number of the requests appear to be from valid, local ISP users.

In the exception's request details, the Request URL is different than the Request path:

Request URL: http://www.somesite.com/Images/Image With Space.jpg

Request path: /Images/Imagehttp://www.somesite.com/Images/Image With Space.jpgWithhttp://www.somesite.com/Images/Image With Space.jpgSpace.jpg

Notice that in the "request path", any place there is a "space" in the path is replaced with an exact copy of the request url!

Within the site, the actual link looks like this:

<img src="/Images/Image%20With%20Space.jpg" />

Any idea what might be causing this? I tried to look at the documentation for Request.Path and Request.Url, but I can't figure out why they would be different. Hitting the Request URL directly brings up the resource correctly.

Update: I managed to get a trace of one of the malfunctioning requests by using IIS 7.0's Failed Request Tracing feature:

Referer: Google search

User-Agent: Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3

RequestURL: http://www.somesite.com:80/Images/Image%20With%20Space.jpg

Typing the URL manually into my iOS 5.1.1 brings up the image correctly. Searching for the image in Google Images brings up the image correctly. Still no successful reproduction.

Partway down the trace I see:

MODULE_SET_RESPONSE_ERROR_STATUS Warning. ModuleName="RequestFilteringModule", Notification="BEGIN_REQUEST", HttpStatus="404", HttpReason="Not Found", HttpSubStatus="11",

According to IIS' documentation, 404.11 from the Request Filtering module is a "double encoding" error in the URL. Experimenting a bit, if I purposefully create a double encoded url such as http://www.somesite.com/Images/Image%2520With%2520Space.jpg I get the exact error in the event log, complete with malformed Request Path.

The malformed Request Path in the event log error appears to be a bug in ASP.NET 4.0.

It doesn't, however, explain why I'm getting the error in the first place. I checked a large number of failed request logs - the only common factor is that they're all using AppleWebKit. Could it be a bug in Safari?

Answer 1

The httpRuntime section of the Web.Config can be modified to adjust the URL validation. ASP MVC projects are usually running in the validation mode 2.0 and the default invalid characters (separated by commas) are listed below.

<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="&lt;,&gt;,*,%,:,&amp;,\" />

As you can see the % sign is considered invalid. A space can be encoded to %20 causing the validation error. You can just add the requestPathInvalidCharacters attribute to the httpRuntime section in your Web.Config file and copy the values I listed below except for the "%," part.

Scott Hanselman has a blog post about this issue:

http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx

Answer 2

I can't help thinking that - given the restricted user-agent - this might represent incorrect handling of the URL by that browser on IOS 5.1.1. I don't personally own such a device so I can't test this - but it would be interesting to investigate how it behaves with a url that actually has spaces in it instead.

I have a feeling that it's seeing the %20 in the url from the page source and double-encoding it, thinking it's being helpful. The problem there being that IIS will decode it back (before ASP.net kicks in) and throw it's rattle out of it's pram because now it sees a literal %20 instead of a space.

I personally don't recommend modifying your servers' security settings; however it would be the easiest solution so I dare say that's what you will do.

Rather, I think if you can confirm this 'bug' (I'm already on the road, finding a safe hiding place from Apple's lawyers), find a format that works for this device; or take all the spaces out of your resource urls. A - is the best alternative.