0

I have an ASP.NET site (Web Forms) running on IIS 8.5 / Windows Server 2012 R2. Occasionally, a user will access the site and seemingly trigger a bunch of malformed page requests coinciding with their normal, legitimate requests, with the protocol and domain repeated in the URL.

For example, the user might start on the home page, initiating a request for https://www.example.com/. This request looks normal in the IIS logs as /. At the same time, the server processes another request for https://www.example.com/https:/www.example.com/, and shows up in the logs as /https:/www.example.com/. Note the leading slash, and the single slash replacing double slashes after the colon.

The site requires authentication, so the user is then transferred to the login page (/login.aspx), which again coincides with a bad request (/https:/www.example.com/login.aspx). It goes on and on, and the user seems to have a normal browsing session based on their navigation sequence, but with each page request matched with an invalid request.

The invalid requests usually throw an HTTP error 500 (Internal Server Error), though sometimes it's a 404 (Not Found). I have not been able to exactly duplicate the issue - if I manually go to one of the invalid URLs, it throws a 400 error (bad request) and displays the normal error page, which suggests the user is not making a standard request when these errors occur.

The reported error in my application logging is:

A potentially dangerous Request.Path value was detected from the client (:). Base Stack Trace: System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (:).

Note that this is not a matter of implementing URLs with invalid characters and trying to allow it. In this case, my URLs are acceptable and some other process is triggering requests with invalid characters.

Aside from the error code, an invalid request also does not include a browser user agent string in the IIS log. There is about a 20 second delay in the invalid request before it is logged, which seems to be the time the server takes to process it before throwing the error.

These users are known, authenticated customers, and nothing appears to be malicious in their behavior. There are no suspicious query string parameters or attempted calls to inappropriate pages. The invalid requests only correspond to page requests - nothing for images, javascript, css, etc, which are served directly by IIS, but also nothing for .axd files served by ASP.NET. The invalid requests don't require the user to be logged in, as I've seen it occuring on a password reset page.

The majority of users seem to be using Internet Explorer 11, though the operating system might be Windows 7, Windows 8, or Windows 10. There's nothing in the user agent strings suggesting a common plug-in. It's not a common thing to encounter, but happens several times per month. It's not always the same user, but some users have been affected repeatedly over time, and it does not affect them every single time (e.g. if they're using a different device).

The issue started in April 2014 according to my logs, and I've looked into it over the years, but it didn't seem to be a performance or security problem. However, it recently coincided with an unknown server resource issue that brought the server to its knees, so I want to make sure there isn't some avoidable danger.

Is this something anyone else has encountered?

Stark Raving
  • 400
  • 1
  • 3
  • 7
  • Possible duplicate of [Getting "A potentially dangerous Request.Path value was detected from the client (&)"](http://stackoverflow.com/questions/6025522/getting-a-potentially-dangerous-request-path-value-was-detected-from-the-client) – Iłya Bursov May 02 '17 at 17:48
  • @Lashane, in my case, I'm not trying to allow invalid characters, and my pages don't include invalid characters. Some other thing is triggering requests with invalid characters. – Stark Raving May 02 '17 at 18:02
  • Long shot, but did you ever find a solution as to what was causing these? I have an IDENTICAL situation, all these years later, with an old classic ASP website. – Ralpharama Sep 08 '21 at 10:42

0 Answers0