Wednesday, December 29, 2010

Re: Help with Custom GWT RPC

Thanks Sri. That makes complete sense. I'd totally forgotten about
CSRF.

On Dec 29, 11:12 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> > *Also, in the discussion I saw about this, it was said that it was
> > more secure to send the session ID in the RPC itself instead of getting
> > it from the header/cookie. Why is this? Does GWT add something extra like a
> > hash to make sure the RPC hasn't been tampered with?*
>
> *
> *
> *GWT doesn't do anything special with RPC to make it tamper-proof. *
>
> The cookie is treated specially by the browser.  The browser will
> automatically send the cookie to the server regardless of any client or
> server code explicitly asking for it. If you rely blindly on it, your code
> will be susceptible to CSRF attacks.
>
> A header cannot be manipulated easily. If you "double-submit the session id"
> - once in a custom header and once in the session cookie - and then compare
> that both the ids are same - you prevent CSRF. If you prefer, you can also
> send the header as a GET parameter.
>
> But why maintain the session id in the cookie if it is such a hassle?
> Because that way you can leverage your application servers/frameworks
> inbuilt session handling mechanism. There is no point in re-inventing the
> wheel.
>
> If you haven't done so, please read GWT
> security<http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gw...>to
> understand why this "double submit session id" approach works.
>
> For code, see notes below -
>
> *Client Side*
>
>    1. RPC async interface implements ServiceDefTarget. Using this interface,
>    you can set a custom RpcRequestBuilder
>    2. In your custom RpcRequestBuilder, override the doCreate() call
>    super.doCreate() and get an instance of RequestBuilder
>    3. Once you get the instance of RequestBuilder - add a custom http header
>    via the setHeader() method. The value of this header would be the session
>    id.
>    4. See code below -
>
> //In a global file
> public static final RpcRequestBuilder global_rpc_request_builder = new
> RpcRequestBuilder() {
>  @Override
> protected RequestBuilder doCreate(String serviceEntryPoint) {
>  /*
>  * This RequestBuilder is used to make a RPC request
>  */
>  RequestBuilder builder = super.doCreate(serviceEntryPoint);
> builder.setHeader("SESSION_ID", getSessionIdFromCookie());
>  return builder;
>
> }
> };
>
> //Before invoking RPC method
> GreetingServiceAsync greetingService = GWT.create(GreetingService.class);
> ((ServiceDefTarget)greetingService).setRpcRequestBuilder(global_rpc_request_builder);
>
> //Now invoke the RPC method
> greetingService.greetServer("Hello World", callback);
>
> *Server side*
> This is straightforward - read the header from the request object, and
> compare the session id in header with the one you get from the session
> cookie.
>
> --Sri
>
> On 29 December 2010 21:01, Falcon <msu.fal...@gmail.com> wrote:
>
> > Also, in the discussion I saw about this, it was said that it was more
> > secure to send the session ID in the RPC itself instead of getting it
> > from the header/cookie. Why is this? Does GWT add something extra like
> > a hash to make sure the RPC hasn't been tampered with?
>
> > On Dec 29, 9:24 am, Falcon <msu.fal...@gmail.com> wrote:
> > > I'm trying to send the session ID with every RPC request my GWT
> > > application makes and handle our login context. On the server, it
> > > looks like you can handle that by overriding
> > > onAfterRequestDeserialized() and onAfterResponseSerialized() (we don't
> > > need to add any information to the outgoing payload, just destroy the
> > > login context, so we can do this after serialization).
>
> > > However, I'm not sure what I need to override on the client since
> > > RemoteService is just an interface. I know GWT is doing some magic
> > > with GWT.create(). Ideally, I'd like to extend RemoteService with a
> > > new class, then extend that new class for all of my RPCs that needed
> > > to send the session IDs automatically and then put the session ID
> > > somewhere in the payload before the RPC was serialized to send across
> > > the wire to the server. This just seems to make more sense to me than
> > > having the session ID be a part of every single RPC method signature.
>
> > > Any help would be appreciated! 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+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