An Autonomous Zone

Grendel-Scan is a new(ish) web application scanner that a friend of mine is writing. One of the cool things that I like about Grendel is it’s Cross Site Scripting (XSS) vulnerabilitiy detection.

The way David approached the XSS vulnerability scanning cuts down on the amount of requests being made to the web application as well as the number of false positives as compared to other scanners that I’ve checked out.

Like all web application scanners when trying to detect non-persistent XSS Grendel substitutes a known parameter value for a value that includes javascript code. As mentioned in my previous posts it might change something like this:

param=123

to something like this:

param=123/><SCRIPT>alert(’XSS’);</SCRIPT>

Generally when the scanner sees the signature included in the response (/><SCRIPT>alert(’XSS’);</SCRIPT> in the above example) then they’ll flag it as a possible XSS vulnerability.

Now for the most part a web app scanner will have many, many different XSS signatures (different javascript-type parameter substitution values) that it will try on a particular parameter value. For instance, for the sake of thoroughness a web app scanner might have 40+ different XSS signatures that it will try for each and every parameter that it records going to the application to detect XSS.

Like I mentioned most scanners are extremely inefficient and noisy in the sense that they’ll continue to submit as many requests as there are XSS signatures until it flags a particular request as being vulnerable to non-persistent XSS. So if there are 53 XSS signatures a typical scanner will submit 53 requests per parameter (again, unless it flags a request within the 53 signatures that it sends as being vulnerable).

If you’re scanning an application that has a lot of parameter values (like hundreds or thousands) being sent in a request, as most applications do, this can end up being a lot of traffic being sent to the application being scanned.

If you’re scanning a staged or development environment this usually isn’t too much of a concern but if you’re scanning a production environment – this can cause concerns. One of the biggest problems with sending out all of the XSS signatures per parameter in an application (besides bandwidth and resource saturation) is form submissions that generate emails. For certain form submissions on a number of applications, such as a “Contact Us” form the submission information is emailed to a particular person or persons within the organization who is in control of the application. This generates one email per request sent to the particular form.

This means if you have a form that has 10 parameters and your app scanner has 53 XSS signatures you’ll have at around 530 emails being sent to someone – keeping in mind this is only for XSS detection. You’re likely to have a whole lot more submissions being sent and emailed to someone when you’re scanner is looking for other issues like SQL injection vulnerabilities, CRLF vulnerabilities, directory traversal vulnerabilities, etc. At the end of the scan it’s very, very possible someone will open their mailbox and have thousands of junk emails from scanning the site.

So – what does David do different when discovering XSS with Grendel? Before throwing each XSS signature at every parameter Grendel will first send a random value (a token) as a parameter value with a fixed 4 digit prefix (keep in mind that in order for an application to be vulnerable to non-persistent XSS it first has to echo back the parameter value in the response).

So it’d be something like this:

param=fds5fds34

Each response is searched for the prefix. The fixed four digit prefix (fds5) doesn’t change throughout the scan – which makes it easier to look for tokens in responses. If the prefix is found then the six characters following it are looked up (that way you don’t have to search for every token in the response).

If Grendel sees the token being returned in a response only then will it continue to send the XSS attack signatures. This cuts down on the amount of “useless” XSS attack signature requests being made to the web server. If the application doesn’t echo back a token value – then it’s not going to be vulnerable to non-persistent XSS in the first place.

Not only is this a lot better for production sites, it cuts down on scanning time because less meaningless requests are being sent to the application.

Another thing that David has done to reduce false positives with XSS is he’s implemented the Rhino javascript engine from Mozilla into his scanner. This way a XSS vulnerabilitiy is cataloged with Grendel only if the response triggers the javascript engine to fire.

This cuts down on XSS false positives tremendously. As a neat bonus he’s included a module called input/output flow that records any request that responds with a token value – just in case there is a posibilitiy of a XSS issue being present but the supplied XSS attack signatures was not able to trigger the javascript engine.

Grendel was released at DEFCON last year and becuase of his hectic work schedule he hasn’t updated it much in the last few months but I hear he (and a few others) are working on it now and should have a new release really soon.

You can find it here: http://www.grendel-scan.com/

Cheers,

ChuckB.