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
> 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 <b...@cirosec.de> 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 <sripathi.krish...@gmail.com>
> > 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 <b...@cirosec.de> 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 <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/>.
> > > > > 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 <b...@cirosec.de> 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
> > > > google-web-toolkit@googlegroups.com.
> > > > > > To unsubscribe from this group, send email to
> > > > > > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > <google-web-toolkit%2Bunsubscribe@googlegroups.com<google-web-toolkit%252Bunsubscribe@googlegroups.com>
>
> > > > <google-web-toolkit%2Bunsubscribe@googlegroups.com<google-web-toolkit%252Bunsubscribe@googlegroups.com>
> > <google-web-toolkit%252Bunsubscribe@googlegroups.com<google-web-toolkit%25252Bunsubscribe@googlegroups.com>
>
> > > > > > .
> > > > > > 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
> > google-web-toolkit@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > <google-web-toolkit%2Bunsubscribe@googlegroups.com<google-web-toolkit%252Bunsubscribe@googlegroups.com>
>
> > > > .
> > > > 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 google-web-toolkit@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > .
> > 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment