--Sri
On 29 September 2010 17:14, Basdl <bz@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
>
> > <google-web-toolkit%2Bunsubscribe@googlegroups.com<google-web-toolkit%252Bunsubscribe@googlegroups.com>> 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>
>
> > > > .
> > > > 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.
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