1

We have a strange exception on our ASP .NET Webforms application.
The same exception is being sometimes thrown one different .aspx pages:

Error: This is an invalid webresource request. URL: https://example.com/WebResource.axd?d=pPvrniqvKCVu4785dN_ahQGLCPzNyr7f4i8DaZgJq2QNfEAadKjdL1N4XhlkzuMFZMX2X0-RCOI_z1vzc5RFMGIe7CAXw7lJqHZw5nlyodAkssADb-0obxsyzubFHcCM-5Kt0Zfm8W7ao0HE6xyQsaV264sX_gMQYPnzPGzAMMk1&t=636618914162471727

Source is System.Web

This is an invalid webresource request. at System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

It has started after we've upgraded our server from Windows Server 2012 R2 to Windows Server 2016.

I've tried:

  1. Upgrading .Net Framework to latest 4.7.2
  2. Applying the security patch as stated here
  3. Made sure it's not a crawling bot as stated here (the exceptions are being thrown sometimes even when browsing the page through our IP)
  4. This answer, #1 completed, #2 irrelevant as it happens also from our IP, #3 we don't run any farm.

The problem is that we don't see these exceptions on localhost, and have no idea how to debug the reason for it on the server.
Any idea would be much appreciated.

Yan
  • 433
  • 2
  • 16
  • Step through starting in Global.asax Application_Start. (?) Check server logs for more detail or even local machine logs (event viewer). – wazz May 16 '18 at 06:33
  • Unfortunately, there are no local events that can point to this problem. I will go through Global.asax to see if I can find something. Thanks. – Yan May 16 '18 at 07:00

1 Answers1

1

This is a comment rather than an answer. But I just signed up and don't have enough reputation to comment. Apologies.

These invalid requests to WebResource.axd happen because all of that encrypted junk in the URL does not decrypt to anything meaningful on the server. There are a few reasons this might happen:

  1. A client/browser has cached an old link from before a recent server patch changed how the encryption/decryption works on the server side - such as the MS10-070 patch one of your links refers to. I wouldn't expect these invalid requests to be very plentiful in your logs and they should go away eventually. I am not aware of any recent patches that affect ASP.Net like this though, so this is proably not your problem.
  2. A malicious agent is scanning to see if your site is vulnerable to attack. Again, the vulnerability patched by MS10-070 is the example that springs to mind. If this is the case, you would likely see multiple attempts to access WebResource.axd with slightly different query strings while it probes for the information it needs. Just because you have patched your server, that does not necessarily mean you won't see a malicious agent checking your site out.
  3. It could be a bug with your client. IE8 had a bug that was corrupting the encrypted part of these WebResource strings a few years ago. Do your server logs track the user agent string of the client? Are these bad requests coming from the same client? Same family/version of browser?

There are any number of ways this query string might get gunked up, and most of them happen between the time it leaves the server in a valid response and it returns in a subsequent request. Here are some questions I would answer to help narrow the issue down a little. Is the url that causes the error actually invalid? Or does that exact same url result in success most of the time? Do you know what page is being served that includes the link to this particular WebResource.axd? If you request it manually, what does the expected query string look like? How similar is it to the bad string?

Steve Molloy
  • 111
  • 2
  • One more comment regarding #1 - changing the encrypt/decrypt behavior doesn't have to be the result of a security patch. There is nothing I'm aware of from ASP.Net itself that will force a change like this on you in the last few years. But anyone who can change machine.config/web.config for your application can change the machineKey and accompanying validation parameters. Double check to make sure nothing has changed in this area in your config stack if you suspect #1 might be the case. – Steve Molloy May 29 '18 at 22:53
  • Thank for the clarifications. - The URL that causes this error isn't invalid. - It is not the same URL - It is the same WebResource.and URL (incl. the query string itself) - different web-clients and even different IP's - I don't request it manually; actually I'm not sure what part of the code requests it, might be some aspx control Do you have a clue? – Yan May 30 '18 at 07:19
  • WebResource.axd is an all-around-handler for ASP.Net that serves up supporting resources - mostly javascript - for different ASP.Net features from the days of 2.0. Things like TreeView and what not. The link is included in page responses whenever certain features are used on a page, and the browser can then get the javascript and load it. The link generated by ASP.Net in the response will always be correct for the server that generated it -- as long as the server doesn't change its configuration between the page response and the subsequent request for the resource. – Steve Molloy May 31 '18 at 16:02
  • That means the query string text is getting messed up somewhere after the original page response is generated and before the WebResource.axd request reaches ASP.Net. This could be happening in a mis-behaving proxy. It could be happening in an old buggy version of IE8. It could be happening in a different buggy client that we are unaware of. It could be a malicious user trying to probe WebResource.axd as a padding oracle. Or it could just be that somebody has an old link to WebResrouce.axd cached from a long time ago before server configuration changed. – Steve Molloy May 31 '18 at 16:05
  • Comparing the bad query string to known good query strings that show up in your IIS logs could give a clue about where the problem lies. IE was randomly dropping a chunk of the string. It would all look good and similar to other good strings, until it didn't. If a proxy is gunking things up, there might be similar missing sections in the string. Maybe there is an identifiable pattern for the lengths that go missing compared to good requests. Maybe the successful requests right around the bad one could give you a clue about what feature or class of client is having trouble. – Steve Molloy May 31 '18 at 16:10