Vulnerabilities in GWT applications

[Basdl]

Hello,

I'd like to find vulnerabilities in my GWT applications.
Thus, I prepared an example application with SQL injection
and cross-site scripting holes.
Now I want to find these holes with automatic tests.
In my opinion, a static analysis is a reasonable way to do this.
At (manually) searching the generated javascript, I located
my variables in the first script-tag in the body and the
corresponding function in the 18th script tag.

Now I have the following questions:
- Is there a documentation of the GWT compiler available,
that shows how the java source is translated into javascript?
Hence, I could inspect only the part of the javascript
that is related to my self-coded java and not to the framwork.
- How can I identify standard parameters and functions (to skip them)?
- Does anyone know a better solution to find the described
vulnerabilities?
- Do you have some hints to perform such a security analysis?

Thanks in advance

[Sripathi Krishnan]

Lets look at the vulnerabilities one at a time.

Cross Site Scripting (XSS)

With GWT, the attack vectors for XSS are restricted to the following - 

1. Host html/jsp page that has reflected XSS
2. Custom Javascript libraries
3. JSNI code that you have written within GWT
4. Places where you have called eval(), or have used built-in JSONParser to parse untrusted JSON
5. Code that assigns window.location on untrusted strings
6. Code that uses setInnerHtml on untrusted data

This isn't an exhaustive list, but represents the most common attack vectors for a GWT app. If you do a manual code-review for these patterns, you will catch most of your XSS problems. And if you are GWT app follows best practices, you really won't be using most of the above patterns.

SQL Injection

This is largely outside the scope of GWT, but there are a couple of things you can do.

• Do a manual code-review for SQL Injection. OWASP website has good code-review checklists, that's the best resource.
• Use an automated scanner to perform the tests. The problem is that GWT RPC doesn't play well with automated scanners. You may find the following blog posts useful to get around this problem - 
  http://www.gdssecurity.com/l/b/2010/05/06/fuzzing-gwt-rpc-requests/
  http://www.gdssecurity.com/l/b/2010/07/20/gwtenum-enumerating-gwt-rpc-method-calls/
  

Cross Site Request Forgery

If you are using the latest GWT version, you are largely protected from CSRF. GWT includes a custom http header in each RPC request, and that takes care of CSRF on most browsers. The only vulnerable ones are people with outdated versions of Flash Player.

If you are paranoid and want to protect the users who don't upgrade their browsers, read this post on Lombardi's blog. IMHO, you should do that only if you are using an older version of GWT and can't upgrade.

Lastly, if you want to de-obfuscate some of GWTs code to perform security analysis, you might want to check out degwt. It has a bunch of useful notes and a couple of bookmarklets, but I am still working to complete that library.

Hope that helps!
--Sri

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Basdl]

Thank you for this detailed reply.
I think the tools you suggested provide most I need.

A manual code-review might sometimes be too time-consuming.
Therefore I thought about to analyse the javascript to extract the
possible
requests and then manipulate these to find the security holes.
My understanding by the analysis is done by degwt.
I just have to figure out how to test my RPC calls (maybe with one of
the other tools).

Now I have to take a closer look to degwt.
I'd like to get most of the tests automated.
At the moment I have tried to write a java application to examine
the javascript file. With your admission I'd try to port some
functionality
of degwt into my java application.

Best regards
Basdl


On 28 Sep., 21:29, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> Lets look at the vulnerabilities one at a time.
>

> *Cross Site Scripting (XSS)*

> With GWT, the attack vectors for XSS are restricted to the following -
>

>    1. Host html/jsp page that has reflected XSS
>    2. Custom Javascript libraries
>    3. JSNI code that you have written within GWT
>    4. Places where you have called eval(), or have used built-in JSONParser
>    to parse untrusted JSON
>    5. Code that assigns window.location on untrusted strings
>    6. Code that uses setInnerHtml on untrusted data

>
> This isn't an exhaustive list, but represents the most common attack vectors
> for a GWT app. If you do a manual code-review for these patterns, you will
> catch most of your XSS problems. And if you are GWT app follows best
> practices, you really won't be using most of the above patterns.
>

> *SQL Injection*

> This is largely outside the scope of GWT, but there are a couple of things
> you can do.
>

>    - Do a manual code-review for SQL Injection. OWASP website has good

>    code-review checklists, that's the best resource.

>    - Use an automated scanner to perform the tests. The problem is that GWT

>    RPC doesn't play well with automated scanners. You may find the following
>    blog posts useful to get around this problem -
>    http://www.gdssecurity.com/l/b/2010/05/06/fuzzing-gwt-rpc-requests/
>

>    http://www.gdssecurity.com/l/b/2010/07/20/gwtenum-enumerating-gwt-rpc...
>
> *Cross Site Request Forgery*

> If you are using the latest GWT version, you are largely protected from
> CSRF. GWT includes a custom http header in each RPC request, and that takes
> care of CSRF on most browsers. The only vulnerable ones are people with
> outdated versions of Flash Player.
>
> If you are paranoid and want to protect the users who don't upgrade their

> browsers, read this post on Lombardi's blog <http://jectbd.com/?p=1351>.

> IMHO, you should do that only if you are using an older version of GWT and
> can't upgrade.
>
> Lastly, if you want to de-obfuscate some of GWTs code to perform security

> analysis, you might want to check out degwt<http://code.google.com/p/degwt/>.

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

[mP]

Hiho

SQL injection is only a problem if you write crap code on the server
that builds SQL queries as a String rather than a Statement with
parameters that one sets. This problem exists for all kinds of web
apps if you do the wrong thing and not GWT exclusively. XSS is also
caused by writing and not escaping Strings that one has previously
received from a user. For example they post a string with some
javascript embedded inside which the app writes straight back and is
executed by the browser. Do the write thing and the problem
disappears...

tya

[Sripathi Krishnan]

If you have access to code, there are existing static analysis tools that will go through the java code and identify SQL Injection vulnerabilities. I haven't used any before, but I do know they do a decent job. Static Analysis + Manual Code Review is a better way to catch SQL Injection issues, IMHO.

But if you don't have access to code (if you are pen-testing), then you would have to build something on your own. DeGWT was meant to be that tool, but I never really completed it. 

If you are interested in porting degwt to Java - YOU ARE WELCOME! It is possible to completely reverse-engineer the RPC interfaces from generated javascript, it just needs a little time to work on it. DeGWT right now only enumerates the methods, so the next step is to figure out the parameters and the return type. I have some notes on how to do that, I'll update the wiki if you are interested.

--Sri

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Basdl]

You are right, but when you use 3rd part code or develop a large
application you can't ensure that you have no such security problem.
I'm interested to find these (and other) security holes in GWT
applications.
Current security scanners that work with other web applications fail
in
inspecting gwt applications.

[Basdl]

Unfortunately, I just sometimes have access to the java source code.
And I think I can't identify some other security holes like access a
admin area
by finding a (for normal users) unused RPC call or something like
that.

DeGWT is a nice tool to start with to analyse GWT applications without
having access to java source code. I would be glad if you can povide
my more
information. I have read something about the structure of RPC calls on
a related site
of your first link (http://www.gdssecurity.com/l/b/2009/10/08/gwt-rpc-
in-a-nutshell/).

I'll try to develop a tool for the analysis in java.
I'm thankful for every information I could get.

You helped me a lot.
Basdl

On 29 Sep., 13:04, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> > <google-web-toolkit%2Bunsu...@googlegroups.com<google-web-toolkit%252Buns...@googlegroups.com>

[Sripathi Krishnan]

To get started, you should read the documentation over here - http://code.google.com/p/degwt/wiki/HowDeGWTWorks. You should also play around with the bookmarklet. I usually log-in to Orkut.com and invoke the bookmarklet to see the list of RPC methods.

--Sri

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Stefan Bachert]

Hi,

First let us clarify what "GWT App" may mean:

a) the browser part compiled to JavaScript
b) The server part, still running in Java
overall app mean a) + b)

a) is always untrustable. Any attackers could substitute the client by
anything he/she likes.
Even when you deliver the best secured browser client, it does not
increase the security of your overall app.

b) GWT-RPC does some automatic improvements, however, you must check
any input because there is no guaranty to come from a trusted and
honest source.
However, server side is still java, any java techniques for security
may apply. This is hardly a GWT topic.

I don't think there is an automatic way the find vulnerabilities.
Without understanding classical attack vectors and a great inspiration
of finding potential new ones, you won't increase security.
This will always be a manual task for a human being.

When you need a second pair of professional eyes, you may contact me.
Your site is one hour from my site.

Stefan Bachert
http://gwtworld.de

[Basdl]

I have read this documentation.
My next step is to port DeGWT to java and modify it to cover my needs.
I'll post my results for the different steps.

Basdl

On 29 Sep., 16:26, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> To get started, you should read the documentation over here -http://code.google.com/p/degwt/wiki/HowDeGWTWorks. You should also play

> > > > <google-web-toolkit%2Bunsu...@googlegroups.com<google-web-toolkit%252Buns...@googlegroups.com>
> > <google-web-toolkit%252Buns...@googlegroups.com<google-web-toolkit%25252Bun...@googlegroups.com>

[Basdl]

Hi,

I want to find security holes in a) and b).

I know that a) is always untrustable but there are some thigs to check
out
e.g. read / write of window.location or use setInnerHtml on untrusted
data as
Sripathi Krishnan said.

With the knowledge of possible GWT-RPCs I can try to attack b).
Thus, I can check If the input is validated correctly on the server.

Testing a GWT application without of knowing what the parameters in
GWT-RPCs mean it's very time-comsuming
So I hope to retrieve some information automatically.

But you are right, finding security holes is also a manual task.
No scanner or other application will find all security holes.

Basdl

On 29 Sep., 17:08, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> First let us clarify what "GWT App" may mean:
>
> a) the browser part compiled to JavaScript
> b) The server part, still running in Java
> overall app mean a) + b)
>
> a) is always untrustable. Any attackers could substitute the client by
> anything he/she likes.
> Even when you deliver the best secured browser client, it does not
> increase the security of your overall app.
>
> b) GWT-RPC does some automatic improvements, however, you must check
> any input because there is no guaranty to come from a trusted and
> honest source.
> However, server side is still java, any java techniques for security
> may apply. This is hardly a GWT topic.
>
> I don't think there is an automatic way the find vulnerabilities.
> Without understanding classical attack vectors and a great inspiration
> of finding potential new ones, you won't increase security.
> This will always be a manual task for a human being.
>
> When you need a second pair of professional eyes, you may contact me.
> Your site is one hour from my site.
>

> Stefan Bacherthttp://gwtworld.de

[Thomas Broyer]

On Sep 29, 5:54 pm, Basdl <b...@cirosec.de> wrote:
> Hi,
>
> I want to find security holes in a) and b).
>
> I know that a) is always untrustable but there are some thigs to check
> out
> e.g. read / write of window.location or use setInnerHtml on untrusted
> data as
> Sripathi Krishnan said.

You'd probably have better luck searching all occurrences of
HasHTML.setHTML and/or Element.setInnerHTML and/or Window.Location and
manually checking, than trying to write a robot to find holes for you.

> With the knowledge of possible GWT-RPCs I can try to attack b).
> Thus, I can check If the input is validated correctly on the server.

If the goal is to check your code, as opposed to GWT
RemoteServiceServlet and associated RPC serialization, then how about
just calling your methods in pure Java, without resorting to "GWT-RPC
over HTTP".

[Sripathi Krishnan]

Thomas and Stephen - 

Completely agree that if you are testing one specific GWT application that you have developed, it is always better to

• grep for XSS vulnerabilities, 
• manual code review + directly invoking RPC services from a java program for SQL Injection.

But what if you are doing a black-box security review, and don't have a access to the code? The above techniques don't work in that case.

There are automated scanners for regular web-applications, but AFAIK, there is nothing in the market for penetration-testing a GWT application. From what I understand, @Basdl is a security professional, and is probably assigned the job of testing a GWT application someone else built. In that case, there is nothing much he can do but to write a tool that does some reverse engineering of GWT generated code. 

I had started degwt to build that reverse-engineering tool to be used in such cases, but as with most open source projects, I lost steam half-way through. Its not useful for most people in this mailing list, because the vast majority will always have access to code. But for a few people like me and Basdl, I believe it has some potential.

--Sri

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.