With GWT, you are isolated to the following attack vectors -

   1. Using native eval()
   2. Using setInnerHTML() methods
   3. Using non-gwt javascript code/thirdparty js libraries
   4. XSS on the host html/jsp page

Check-list to prevent XSS for GWT applications -

   - Don't EVER use eval() directly. There is hardly ever a need to use it.
   Remember - eval is evil.
   - Avoid using setInnerHTML directly. UIBinder should take care of 80-90%
   of your use cases. When you must use it, be careful to html escape any data.
   Standard HTML encoding apply - refer to OWASP's xss
cheatsheet<http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet>for
more information.
   - Avoid using external JS. If you have to, use a trusted library, or be
   prepared to review the code
   - Use GWTs RPC - it will help you avoid XSS. If you cannot use RPC and
   are forced to use JSON/JSONP - use a safe JSON Parser. Search GWT forum -
   you will find a thread that discusses safe JSON Parsing. Additionally, the
   server that is generating JSON can take care to encode the data (this would
   need to follow javascript escaping rules described in OWASP's cheatsheet)
   - You will have to take care of encoding data to avoid XSS on the host
   html/jsp. This has nothing to do with GWT - and the techniques described on
   OWASPs website/Internet are good enough for this purpose.

Additionally, you may want to read Security for GWT
Applications<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications?pli=1>-
it introduces XSS and CSRF, and then explains what you can do to avoid
them.

--Sri


On 29 June 2010 02:00, Erem <ehb...@gmail.com> wrote:

> Hey guys,
>
> Most security papers I've read on the topic of XSS prevention suggest
> escaping untrusted strings in a context-sensitive way in server side
> templating languages. However I sense that it's different with GWT
> (and any other JS applications) in that received data from a data
> source can be used in so many different ways before, during, and after
> it is inserted in the page. This is particularly true when your GWT
> application is simply hitting a data source for JSON or XML.
>
> For this reason, it seems like best practice would be to escape in
> your JS/GWT app immediately before writing untrusted data into a
> particular context (javascript, attribute, etc). But at the same time,
> I don't like the idea of possibly dangerous strings buzzing around in
> the browser memory of my clients, waiting for me to forget escaping a
> string before writing it to the DOM.
>
> What effective approaches have you taken with your GWT and JS
> applications to protect against XSS?
>
> Thankee kindly!
>
> --
> 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-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to