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