Question

I am trying for protecting against XSRF attacks GWTP app. The problem facing like JSESSION easliy get in paroz testing tool, using that tools if user is already logged in and at the same time made same server request by paroz. it execute same transaction with updated value, which is a security problem.

To stop that one, Required to create per request new cookie and send from client to server.

@SecurityCookie
public static final String securityCookieName = getRandomString(); //Not work

For ClientModule

public class ClientModule extends AbstractPresenterModule {

    @Override
    protected void configure() {

        bindConstant().annotatedWith(SecurityCookie.class).to(
                NameTokens.securityCookieName);

And in DispatchServletModule

public class DispatchServletModule extends ServletModule {

    @Override
    public void configureServlets() {
        bindConstant().annotatedWith(SecurityCookie.class).to(NameTokens.securityCookieName);

I want to generate cookie randomally instead of ‘JSESSIONID’. How/where to do? And what is a proper way to regenerate cookie per request in GWTP?

Answer 1

For generic gwt, see XSRF protection

It’s for RPC calls:

RPC XSRF protection is built using RpcToken feature, which lets a
developer set a token on a RPC endpoint using HasRpcToken interface
and have that token included with each RPC call made via that
endpoint.

You have to rewrite your rcp calls to be invoked in the callback that obtained the token but it’s not so difficult to implement.

EDIT

I don’t understand the need for a randomized cookie name. For the standard GWT protection, you have to specify a set name:

<context-param>
  <param-name>gwt.xsrf.session_cookie_name</param-name>
  <param-value>JSESSIONID</param-value>
</context-param>

The docs you cited for gwtp state explicitly:

To protect your application against XSRF attacks, as described in
Security for GWT Applications , you have to specify the name of the
security cookie you want to use. Do this by binding a string constant
annotated with @SecurityCookie both on the client and on the server.

I think it doesn’t matter if the user is logged in. Malicious code can not read the JSESSIONID cookie (or whatever cookie you specify) and it needs the value of the cookie (sure it can send the cookie but that does nothing because malicious code need the value so it can calculate a unique token that you send every request). This is what the docs say:

Default XSRF protection implementation derives XSRF token from a
session authentication cookie by generating an MD5 hash of the session
cookie value and using the resulting hash as XSRF token. This
stateless XSRF protection implementation relies on the fact that
attacker doesn’t have access to the session cookie and thus is unable
to generate valid XSRF token

So you do need to specify your cookie name in order to configure it to work, or GWT can not use the value of that cookie to generate the end point token that you obtain prior to every rpc call and include with every rpc call.

So while I don’t think you need to implement your own XSRF protection since you are not using standard gwt, I do think you do need to follow the docs you cite to configure gwtp to use it’s implementation of xsrf protection.