I suggest using container managed security so that you don't have to
deal with most of this.  I have implemented a GWT-based form login,
but it required some hackery because of the way tomcat/glassfish
handle redirecting for form login using request dispatching, therefore
causing your moduleBaseUrl to be off and not being able to load any of
the successive resource files.  I was able to work around this using a
jsp to do a meta redirect so that the browser would go to the real
url.

On Apr 7, 3:57 pm, Sripathi Krishnan <sripathikrish...@gmail.com>
wrote:
> For general ideas on how to implement remember me, the thread you started on
> stackoverflow<http://stackoverflow.com/questions/2594960/best-pratice-to-implement-...>should
> get you answers. I will try to answer the GWT specific things you
> should be doing over here.
>
> If you haven't already, please 
> readhttp://groups.google.com/group/Google-Web-Toolkit/web/security-for-gw....
> Its a bit dated, and will perhaps take you a while to go through it, but it
> is definitely worth reading if you are concerned about security.
>
> Once you have implemented remember-me, it is important that your website
> doesn't have XSS (cross site scripting) or CSRF (cross site request forgery)
> loopholes. Additionally, you must use a SSL certificate (https) to protect
> the cookie from a man-in-the-middle attack.
>
> Some suggestions for XSS and CSRF from a GWT perspective -
>
> *Cross Site Scripting*
>
>    - Within GWT code, be wary of innerHTML() and eval() methods. Make sure
>    that whatever string you pass to these methods is trusted. If its not
>    trusted, you'd have to escape the
> strings<http://www.530geeks.com/encode.jsp>appropriately. GWT takes
> care of things everywhere else.
>    - If you are using JSNI, make sure you don't insert untrusted content
>    into the dom. Same as above, use escaping if the strings are not trusted.
>    - If you use an external javascript library, make sure it doesn't have
>    loopholes.
>    - Finally, if you use a jsp/servlet to generate the html, make sure that
>    it doesn't echo input parameters without first escaping them.
>
> *Cross Site Request Forgery*
>
>    - If you use GWT RPC (whether the legacy one or the new deRPC), you are
>    already protected. GWT sets custom request headers before making a RPC 
> call.
>    It also uses post with a custom content type. These cannot be forged using 
> a
>    script/image/iframe/form from another domain.
>    - If you use RequestBuilder to download JSON / XML, then you are on your
>    own. Follow the best practices laid down by
> OWASP<http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_...>.
>    GWTs security
> notes<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gw...>also
> has notes on how to protect against csrf.
>
> --Sri
>
> On 8 April 2010 02:36, Manuel Carrasco Moñino <man...@apache.org> wrote:
>
> > GWT (client side) has nothing to do with HttpOnly cookies because the
> > browser can not read them using javascript.
>
> > You have to face it in the server side, sending a cookie from your
> > servlet to the browser with the HttpOnly attribute set, the browser
> > will remember it, and the next time it loads the GWT application it
> > has to ask the server via RPC to know if the user has the appropriate
> > cookies, if not you have to show the login screen.
>
> > -Manolo
>
> > On Wed, Apr 7, 2010 at 8:17 PM, yccheok <yancheng.ch...@gmail.com> wrote:
> > > Does anyone have a good code example, on how to implement login/logout/
> > > remember me feature, using GWT, with concern on Cross-Site Request
> > > Forgeries.
>
> > > My plan is to use HttpOnly :
> >http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-http...
>
> > > However, I am not sure whether that will be sufficient enough.
>
> > > Thanks.
>
> > > --
> > > 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+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<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