Using the following probe to test for vulnerabilities on this site:
...the request is intercepted and immediately generates an error page:
An Error occurred
Unknown application error
A potentially dangerous Request.QueryString value was detected from the client (Page="...licies.htm
But on this site, running the same app:
...it executes the XPage method which has code in place to sanitize the Page parameter, so I get this:
Invalid XPage Request
*** Unsafe Content *** does not exist or is not accessible.
While here, I have a potential security problem as the alert is triggered despite the sanitation action:
Why does the same routine produce different behaviors? And how do I avoid that alert on the UNLV site?
--stein
This is based on IIS/ASP.NET Request validation. By default requests that include unsafe characters are not allowed. This includes script tags, angle brackets and path separataors (.\ and ..\ specifically).
The behavior varies for slightly IIS and ASP.NET versions and it can be turned off via the ASP.NET RequestValidation key.
On their own these requests aren't unsafe. It's depending on what you do with the data received that makes it potentially unsafe.
+++ Rick ---
Thanks. Now that I think about it, the latter 2 sites are still running under ISAPI. I'll suggest they move to .NET and make sure the RequestValidation key is on...
--stein
I'm sorry to re-open this tread but I think the question raised by Stein is still open and unresolved. We have the same issues as these kind of requests are being flagged as high risk for XSS and we seem to have no control to resolve them. The RequestValidation key in web.config didn't work.
If this page is returned by the .NET ISAPI handler isn't it time for an update - first to update jQuery 1.12 (which has known vulnerabilities) and second - not to echo any part of the query string back?
Regards Dimitar Hristov
First off you're using ISAPI with wc.dll (according to the URL posted in another thread) which is 20 year old tech that hasn't been updated in 10. So expecting to have things up to date and working with some scenarios that is a bit of stretch.
If you're using the .NET pipeline then turning RequestValidation on in the IIS settings will filter out bad requests at the IIS/ASP.NET level before it ever gets to Web Connection. If I remember right those will return 404 responses. That's useful, but can also cause problems for content that actually needs to contain encoded content like brackets.
If you let those requests get into Web Connection - with query string values, even if you don't handle it, unless somebody is doing something really dump like building static string SQL parameters from raw input, or writing out non-HTML Encoded output, even malicious script code is not a threat.
At that point it's up to your application to handle it. It doesn't make sense that an application checks every URL for script tags, if it doesn't even look at the value much less use them for anything. But that's excatly what these tools do - hit every possible URL on your site with script tags and sql injection code. Of those may 1% might actually have a chance to do damage and then only if one does something dumb in the first place.
So the choices are - using the built-in Request Validation and let the server handle it - with the side effects that can entail on some user input not working - or you can have to do it in the application and be careful with whenever you use user input to never construct static strings for SQL and HTML encode all HTML output.
The main rules to abide by are:
- Never ever build static string SQL Statements - always use named parameters
- HTML Encode all output dynamically displayed from user input
- Securely manage your logins (long passwords, two-factor if necessary)
If you do those three things you've managed 99% of the front end security threats to any Web application.
+++ Rick ---
