pinch — 2014-06-18T01:01:50-04:00 — #1
I'm getting quite a few .NET exceptions in my logs as a result of social media sites requesting images I've designated using open graph, etc. I believe these particular requests are coming from Facebook, and what they're doing is requesting specific images but appending &cfs=1 to the end (i.e. "wide-receiver-rankings.jpg&cfs=1").
I assume that the exception must be causing a problem when someone is sharing my content, but I'm not sure how to avoid the .NET exception and serve the image properly. Here is a sample exception:
Exception type: System.Web.HttpException
Exception message: A potentially dangerous Request.Path value was detected from the client (&).
Request URL: http://www.cheatsheetwarroom.com/images/socialsharing/rankings/wide-receiver-rankings.jpg&cfs=1
Request path: /images/socialsharing/rankings/wide-receiver-rankings.jpg&cfs=1
wwb_99 — 2014-06-24T16:51:13-04:00 — #2
The default settings for url scanning are real tight for content apps where you will get valid but technically bad urls due to badly coded tools. You can back this off very easily -- see http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.requestpathinvalidcharacters(v=vs.110).aspx for some details and http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx for a deeper explanation.
PS: you can't gracefully handle this, the web runtime kicks this off before your exception handling can really step in.
pinch — 2014-06-28T12:07:53-04:00 — #3
Thanks. I was able to remove '&' from the list of invalid characters, and through this I was able to get past the 'dangerous Request.Path' error.
However, now the ASP.net engine just thinks that the URL is pointing to a non-existent resource (presumably because it thinks the '&cfs=1' is part of the file name). Is there a way at this point to strip-off the trailing characters and just serve the image? This will deprive whatever application is requesting the resource of the URL parameters, but at least it won't get an exception. I'm not sure if this is a better solution or not.
Is there any way to determine where these requests are coming from? I can't find much information on the url variables I'm seeing but what little I did find seems to hint that it's coming from Facebook.
wwb_99 — 2014-06-30T11:47:00-04:00 — #4
You could probably strip that pretty easily with a url rewrite or something.