I just updated our website to .NET 4.0 and ever since then I'm getting the following exception.
"A potentially dangerous Request.Path value was detected from the client (:)."
The request URL is: "https://OURDOMAIN:443/:/0"
This request is from many different IPs but the client app seems to always be IE 6.0-8.0.
Why do we keep getting requests for ":/0" and how can we stop this filling our event logs?
Update:
It turns out it was a bad javascript file that was creating the erroneous request. Now I just need to figure out what's going awry in the js file.
The request has to be coming from somewhere.
Do you have an invalid link on your page pointing to it?
Maybe check your Routes in the Global.asax.cs file.
Related
In my web logs I see thousands of error messages like A potentially dangerous Request.Path value was detected from the client (:). and the url in question is something like:
{valid site url}/https:/adserver.video/sync/03635d2e5423be5c297a9b6f812b727e/%3Faction=in&uid=5053622972360253088
As far as I can tell, this isn't coming from anything on my site. Is this an attack of some kind? Or could it be some badly behaved third party js library that I'm using incorrectly? There's nothing on the net about this, so does anyone recognize this url?
I am working on an ASP.NET website. The website's users are sent an email with a link to the site. The link will look something like this:
https://<website>/Default.aspx?LC=<guid>
where the "LC" parameter is their login code. The "LC" parameter is the only parameter we ever put on the link. It's also possible to go directly to the Default.aspx page without a code and type one in at the prompt.
Here's the problem: on rare occasions (but consistently since the site launched), I've been getting an error report from the Global.asax handler that says:
12:24:41 ERROR Global.asax - Application_Error - unhandled error:
System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (&).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
I have no idea why I keep getting these messages. I've tried logging HttpContext.Current.Request.RawUrl to see the actual URL the client is using, but all I ever get is this:
/&
and HttpContext.Current.Request.AppRelativeCurrentExecutionFilePath reports as:
~/&
Is there some way I can log the "real" request and see where this ampersand is coming from? The LC parameter value is always a GUID so it would never have an ampersand in it. Also, this problem does not seem to happen for 99% of the site users. For all I know this is being caused by a bot or something, but if it's happening to real users I'd like to find out why.
We recently implemented a new error page on our website which sends emails to the webmaster containing the most recent server exception. We are running a ASP.NET 4 application, and last night we got many emails that were all the same error:
A potentially dangerous Request.Path value was detected from the client (:).
These errors we have seen before, but the odd thing is the path that is being requested. It is always the path:
http://www.mydomain.com/css/about:blank
I have scoured the different pages and can find no anchor tag that appears to point to any link like this. Is this an issue with our application or something else? In other words, do we need to fix anything or just ignore these?
Also, this path was requested consistently, seemingly by the same users, and often was requested from multiple pages they visited. User-agents ranged from Firefox to IE7 and 8.
Have you done anything like this in your css: background-image:url(about:blank);
This shouldn't generate a http request however so I suspect you might have maybe a ./about:blank in there instead.
Good day, everyone.
I found strange behavior within ASP.NET engine when it handles non-existent URL with whitespace.
When we have normal URL like this one: https://stackoverflow.com/questions/tagged1/c%23
we get normal custom 404 page as was intended by developers (if any).
But here's the bug. Just add some white space like this:https://stackoverflow.com/questions/tagged /c%23
and you'll see nasty ASP.NET 404 error page. Whether such a page should ever be displayed is another story. I've already made some heavy googling, made debugging research, and I can say that in this situation all custom handlers are ignored, global application class (Application_Error in global.asax) are just not reached. Actually, I don't see how can this situation be handled by ASP.NET. Any ideas?
Just as a note, this behavior is related to ASP.NET and ASP.NET MVC (as show on StackOverflow.com example). I tried other sites and found that even Microsoft.com falls into this category (see this: http://www.microsoft.com/en/us%20/default.aspx). Also, we can replace whitespace with %20 sequence with no better result.
Workaround is found.
HttpException is thrown with 'Error executing child request for pageName.aspx' message.
First of all, ASP.NET can't find requested page or route. Then exception is thrown from System.Web.CachedPathData.GetVirtualPathData (actually, from System.Web.CachedPathData.GetConfigPathData, but GetVirtualPathData makes things clear).
Then if we have any error handler, it provides some actions and tries to do something. Here we usually have Server.Transfer or Request.Redirect that moves user to page 404 or more common error page. But. In current situation HttpException is thrown anyway and we get ASP.NET error page. And in this situation Server.ClearError and Server.RewritePath can help: exception is not thrown this way. BUT! Such error handling crashes normal business logic exceptions thrown by our application.
And to resolve new trouble we have to use if/else depending on whether we receive HttpException (so we use ServerRewrite with ClearError) or some exception from our own code. But again, that's good if you provide your own exception classes, but what if not...
Anyway, I consider this a very strange case, especially that Application_Error handler is ignored whilst other application code is still executed.
Edit
As code-way was not the best selection (we can only guess that we have THIS error when exception Message is empty and InnerException is null) the better solution lies within ISAPI rewriter with rule like (\s+(\.aspx).*)|(\s+/) to custom 404 page. Here we catch all requests like /somePage .aspx and /somePath /. When we have whitespace not preceding .aspx or slash but within page name or path part we don't have mentioned problem.
Isn't it just that the request never reaches the asp.net pipeline. If you set up error documents in IIS, wouldn't they be displayed instead of the "nasty page" ?
I'm finding this problem every now and then in my production website, and it has me absolutely stumped...
My app works perfectly in both dev and production, but every now and then, I get an e-mail from my global error handling with this:
MESSAGE: This is an invalid webresource request.
URL: /WebResource.axd
(which means that for some reason webresource.axd was requested without specifying any GET parameters)
I'm not doing anything with webresource.axd myself, I don't get any of my resources through it, it's only used automatically by .Net to serve it's typical JS for validators, etc.
Any idea why this might be getting requested without parameters?
Has anyone encountered this?
That definitely is a bot not doing very good job of crawling your web site. It processes your web form and locates reference to WebResource.axd, for example:
<script src="/site/WebResource.axd?d=MtIW_TBRtZCvAXDMJGwg4g2&t=633772897740666651" type="text/javascript"></script>
The bot expects static JavaScript files only and tries to download it by requesting WebResource.axd without parameters. The result is an exception thrown by System.Web.Handlers.AssemblyResourceLoader class and intercepted by Application_Error in Global.asax.
I believe this exception is harmless - the client will receive 404 error. You can safely ignore it.
We also have all of our errors emailed to us, and we occasionally get those too. They never seem to have a referrer, and the user agent is usually a little wacky. We write them off as bots.
I just checked a couple of the offending client IP's against Arin, and one them belonged to a web-spidering-type organization, so there's a little more evidence for the bot theory.
I would also log the useragent that made the request to WebResource.axd. It wouldn't surprise me if it was a bot crawling your site.
This discussion...
http://www.telerik.com/community/forums/aspnet/spell/this-is-an-invalid-webresource-request.aspx
... and this linked MSDN article...
http://msdn.microsoft.com/en-us/magazine/cc163708.aspx
... might shed a little light (though not much).