GWT App, meet application security via WebInspect

Application security via WebInspect? YES.

If you've ever had the pleasure of testing a Google Web Toolkit (GWT) based application, then you know how difficult it can be with the custom protocol, especially if it is your first time. This article was not written to explain the protocol to you and how to test it manually, as there are other sites for that. And although manual testing should be mandatory in any assessment, it is not feasible to fully test every parameter for every variant of every vulnerability; hence the use of automated scanners to make your testing more efficient, enabling you to do a much more thorough analysis in the time you have. With that said, WebInspect 10.2 is now the first scanner to fully support GWT-based applications.

 

Up until now, I've come across a couple of automated tools that claim to have GWT support but fell a little short of expectations. One scanner, which I will refer to as “Scanner#1,” has a document published on the vendor's website explaining how to configure the tool to scan a GWT app. However, it only instructs you to define the pipe (|) character as a parameter delimiter. This means that it will then tamper with ALL values delimited by the pipe symbol. Will this work? Yes…sort of. Is this what we want? Not really. All values may get tested; however, the scan is going to be highly inefficient and take forever, as many of the pipe-delimited fields cannot be tampered with (as doing so will break the protocol and just elicit an error back from the server). I've seen GWT requests that have several hundred pipe-delimited fields where only a handful of them are actually able to be tampered with. “Scanner#1” would waste a vast amount of time needlessly testing all the fields—if it still could at all—as there are still other factors such as GWT's XSRF token that may prevent it from successfully testing anything.

 

Not too long ago, a second scanner, "Scanner#2," added GWT support to their feature list. Without any details of what this meant, I gave it a shot and piped the scanner through a proxy so that I could see what it was doing. It turns out that “Scanner#2” was only testing 2 fields: the service name and method name fields. As these 2 fields are not even data fields and are used to tell the server which service/method to call, tampering with them will just elicit an error response if no matching service/method exists on the server. Tampering with these fields may only be useful to attempt to discover additional service/method names.

 

So what can WebInspect do for you now?  I'm glad you asked and am quite excited to announce the following details of WebInspect's new GWT support:

hand-shake-love.jpg

  • Full understanding of the GWT payload: This means that WebInspect only tampers with the potentially vulnerable fields of the request and does not waste time tampering with fields that are handled by the GWT framework or otherwise cannot be vulnerable. Not only does WebInspect only test the potentially vulnerable fields, its parser is actually intelligent enough to determine the data type, both primitive and complex, for each parameter and only perform tests which would apply to that parameter. For example, it wouldn't make sense to perform string attacks on a field that is defined to be an Integer, so WebInspect does not waste your time doing so. In the case of elide (obfuscated) types, WebInspect must fall back and fully attack these as the data type cannot be determined.
  • Handling of XSRF tokens: Cross-Site Request Forgery (XSRF) tokens were introduced in GWT 2.3. If this functionality is enabled, every request will have this token to prevent XSRF attacks. This means that if your scanner is not aware of this token, it will not be able to provide the correct value in each request and an error will always be returned by the server. It was very refreshing to discover that WebInspect can now handle testing GWT sites that use the XSRF protection, as well.
  • Handling of different delimiters: Since protocol version 5, the GWT delimiter has been the pipe (|) symbol. However, prior to that, it was \uffff. WebInspect can recognize and handle the different delimiters.
  • Look Ma, no hands!: The best part has to be that there is zero configuration required for this. WebInspect is able to automatically detect and attack GWT payloads!
  • Nothing missing: And of course, the full set of tests are thrown at the GWT parameters as would be for any other regular GET or POST parameter such as XSS, SQLi, Command Injection, RFI, LFI, Directory Traversal, etc., nothing missing.

 

I would like to close out this article with a very big thank you to Jeremy Brooks, a WebInspect developer, for getting the GWT support added to WebInspect!

 

 

Click here to take WebInspect 10.2 for a test drive!

 

 

About HP Fortify on Demand

HP Fortify on Demand is a cloud-based application security testing solution. We perform multiple types of manual and automated security testing, including: web assessments, mobile application assessments, thick client testing, ERP testing, and more. We do this both statically and dynamically, both in the cloud and on premise. 

 

Labels: WebInspect
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Adam Cazzolla is a Sr. Security Consultant with HP Fortify on Demand.


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation