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 On 29 September 2010 14:17, Basdl <[email protected]> wrote: > 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]> > <google-web-toolkit%[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]<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.
