XSS in GWT

[Kurt Dmello]

Hey folks,
I am a relative noob to GWT and have been looking at it from a security code review perspective.  I want to create a set of guidelines for people who have to review GWT code from a security perspective looking for vulnerabilities.

I have read and understood :
http://www.gwtproject.org/articles/security_for_gwt_applications.html

I have also implemented the StockWatcher application by following the tutorial.

In trying to introduce vulnerabilities that I could exploit as a demonstration for what to look for I have failed.  My understanding after reading the article on GWT security was that if tainted data is set using setHTML() or setInnerHTML() on a client widget it will be suceptable to XSS.

I found the HTML() widget to contain a setHTML() routine that took a String and not SafeHTML and set its value to contain a variety of standard XSS exploits such as <script>alert(1);</script>.  It does not produce the expected results.  It seems to me that there is a black list or further escaping that happens underneath the covers.  Is it that I am simply out "popping" out to the right context or is GWT truly immune to XSS.

What should someone performing code review on a GWT app. be looking for ?

Thanks,
Kurt

[Thomas Broyer]

What you're seeing here is browser "sanitization" from innerHTML (not sanitization actually, just that the <script> are not run). Try with <img onerror="alert(1)" src="//"> or similar (onclick, etc.)

 

What should someone performing code review on a GWT app. be looking for ?

Everywhere SafeHtml / SafeStyles / SafeUri could be used but is not (HasHTML#setHTML is one such things)

[Colin Alworth]

Another set of dangerous code to look for would be any SafeHtmlUtils or SafeHtmlBuilder (and their uri/style conterparts) call that should take 'constant' or 'trusted' but instead takes untrusted user data. Custom implementions of SafeHtml should also be treated as suspect.

These all fall under the category of "Deliberately abusing the safehtml api will make it no longer safe".

[Kurt Dmello]

Thanks Thomas,
That was helpful.  I tried the img tag and it did work.

[Ray Cromwell]

Maybe Matthew Dempsky can comment, but I believe there's an error-prone plugin that handles checking for XSS in GWT and bad use of SafeHtml/setHTML.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Kurt Dmello]

Thanks folks,
This is great stuff.  Keep it coming !

I am looking for all potential points of interest in a code review.  Including XSRF and JSON related vulnerabilities.

[Colin Alworth]

For JSON, you'd have go pretty far out of your way to get attacked, like loading something untrusted via JSONP, or manually parsing your own json with eval (rather than any of the safe built-in tools), or, ya know, forgetting to run SSL and having someone intercept your server communication. This isn't GWT specific, you just have to ignore basic web security stuff for these.

GWT doesn't run on the server, so XSRF issues don't really apply to GWT itself. To be attacked in this way, the server needs to accept requests from remote (i.e. attacking) sites without doing something to confirm that they came from the real app. The default RPC and RequestFactory servlets don't do any session or auth management, so don't have a specific vulnerability, but a POST sent to them from an attacking site that is treated as a request from the app itself entirely based on the contents of a cookie (i.e. jsessionid) could be an attack vector. As I said though, RPC/RF don't build in any security but leave it to the app to decide what a user is, what a session is - the code that is reading the HTTP request and deciding that a request is valid is responsible for that. Both RPC and RF have ways to add some content to the body that keyed off of something only a real request from the user should know.