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 <[email protected]> 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/>. > 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 > > On 28 September 2010 16:59, Basdl <[email protected]> wrote: > > > 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 > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Web Toolkit" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-web-toolkit%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
