7
votes

I am running an ASP.NET web application under IIS 7.5 and my Application log is full of errors like this:

Event code: 3012

Event message: An error occurred processing a web or script resource request. The resource identifier failed to decrypt.

...

Exception information:

Exception type: HttpException 

Exception message: Unable to validate data.

at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo, Boolean useLegacyMode, IVType ivType, Boolean signData)

...

Request information:

Request URL: http://www.mysite.com/WebResource.axd?d=l0ngstr1ng0fl3tt3rs4ndd1g1ts 

Request path: /WebResource.axd 

...

How can I prevent them from appearing? As per this link, I have added the following code to my Global.asax file:

void Application_Error(object sender, EventArgs e)
{
  // Code that runs when an *unhandled* error occurs
  //// get reference to the source of the exception chain
  Exception ex = Server.GetLastError();
  string message = ex.Message;
  string path = Request.Path;
  // ignore the following:
  //   errors due to bots trying AXD URLs
  //   errors due to <doNastyThings /> tags in the URLs
  if (
    (ex is HttpException && (path.StartsWith("/WebResource.axd") || path.StartsWith("/ScriptResource.axd"))) ||
    (ex is HttpException && message.StartsWith("A potentially dangerous Request.Path value was detected from the client"))
    )
  {
    // clear the error *to prevent it from appearing in the main Application log*
    Server.ClearError();
    // need to manually direct to the error page, since it will no longer happen automatically once the error has been cleared
    Response.Redirect("/Error");
  }
}

The second group of errors (for potentially dangerous requests) are being caught and repressed by this code; the WebResource.axd errors have already been written to the Application log by the time this code is executed, however. I'm presuming that's because the AXD handler works differently to the standard ASPX handler in terms of error logging (but I have no idea what to do as a result).

All help gratefully received!

3
it looks like the webresource.axd is directly requested without the SSL. Did you find a solution?Cerveser
@Cerveser: I didn't, no -- I learnt to live with it :(Ed Graham

3 Answers

8
votes

I only get this error when I get requests from the Bingbot crawler. You can check if it's the bing bot here

So I added this in my robots.txt file. It doesn't work if you don't add specifically that it's the user-agent Bingbot

User-agent: bingbot
Disallow: /ScriptResource.axd  
Disallow: /combinescriptshandler.axd  
Disallow: /WebResource.axd 
2
votes

/WebResource.axd is generally requested because a page contains a link to it, often an img src:

<img ... src="/WebResource.axd..." />

usually generated from an ASP.NET WebControl, e.g. a Menu control.

I would recommend you locate the page that contains the WebResource.axd reference, see how and why it's being generated, and why it's invalid. For example, you can look at the IIS server logs to find which page immediately precedes the WebResource.axd request, or you can add your own logging to Application_BeginRequest.

Once you've found out the offending page, and identified which control on the page is generating the request, ask again here.

I've seen this in the past in a static HTML page which contains HTML (e.g. a menu) that was copied and pasted from a rendered ASPX page. The request is not valid in a static HTML page, and the fix was simply to remove the offending img element.

2
votes

These errors can be caused when Bingbot does something really stupid and lowercases the URL it requests.

I don't know quite why it does this, but the URL listed in the event log is in fact linked from the affected page - only with some uppercase letters! For example, actual link in the HTML:

https://example.com/WebResource.axd?d=[...]13QzJRP4goegQTwpQQcl[...]

Same link as requested by bingbot:

https://example.com/webresource.axd?d=[...]13qzjrp4goegqtwpqqcl[...]

Oh well... these are clearly harmless errors to be ignored or suppressed.