got XSRF attack when using Super Dev Mode

[Daniel Blanc]

Hi all,

I would appreciate your advices on the following issue :

I have a very basic GWTP application with a single button that trigger an Action.

Everything works fine.

Then I add the following lines in the gwt.xml to enable the the Super Dev mode

  <!-- Super Dev Mode -->

    <add-linker name="xsiframe" />

<set-configuration-property name="devModeRedirectEnabled" value="true" />

I clean everything, recompile and restart. Then I get a security cookie issue, and the dispatcher returns consequently a failure.

It is the same behavior with or without the Code Server.

[INFO] juil. 06, 2014 8:54:48 PM com.gwtplatform.dispatch.rpc.server.AbstractDispatchServiceImpl cookieMatch

[INFO] INFOS: No cookie sent by client in RPC. (Did you forget to bind the security cookie client-side? Or it could be an attack.)

[INFO] juil. 06, 2014 8:54:48 PM com.gwtplatform.dispatch.rpc.server.AbstractDispatchServiceImpl execute

[INFO] GRAVE: Cookie provided by RPC doesn't match request cookie, aborting action, possible XSRF attack. (Maybe you forgot to set the security cookie?) While executing action: com.example.superdevtest.shared.AbortFunplan

It seems the xsiframe linker is breaking the security cookie.

Regards

Daniel

[SP Gingras]

Can you provide a code archive that we could run?

Also, what GWTP version are you using?

[Daniel Blanc]

Actually I created from scratch a project from gwtp-appengine-basic archetype and added an Action +  ActionHandler

I also added the security cookie.

Note I run the server side with appengine:devserver

Find the version used below and the zip file attached of the code :

        <!-- client -->

        <gwt.version>2.6.1</gwt.version>

        <gwtp.version>1.2.1</gwtp.version>

        <gin.version>2.1.2</gin.version>

        <gwt.style>OBF</gwt.style>

        <!-- server -->

        <gae.version>1.9.3</gae.version>

        <guice.version>3.0</guice.version>

        <objectify.version>4.0b1</objectify.version>

        <servlet-api.version>2.5</servlet-api.version>

        <javax.validation.version>1.0.0.GA</javax.validation.version>

        <guava-version>13.0.1</guava-version>

        <!-- testing -->

        <junit.version>4.11</junit.version>

        <jukito.version>1.1</jukito.version>

        <!-- maven -->

        <gwt-maven-plugin.version>2.5.1</gwt-maven-plugin.version>

        <maven-surefire-plugin.version>2.6</maven-surefire-plugin.version>

        <maven-compiler-plugin.version>2.3.2</maven-compiler-plugin.version>

        <maven-resources-plugin.version>2.5</maven-resources-plugin.version>

        <maven-gae-plugin.version>0.9.6</maven-gae-plugin.version>

        <maven-processor-plugin.version>2.0.5</maven-processor-plugin.version>

        <maven-build-helper-plugin.version>1.7</maven-build-helper-plugin.version>

Let me know if I can help 

Regards

Daniel

[Daniel Blanc]

For information I have tested it again with gwtp 1.3 and it worked a couple of time, then I have tested it with my "big application" and got the same security cookie issue. Now I can't run superdevmode anymore on SuperDevTest whatever the clean I do ! 

It seems random.

Has anyone met that same issue ?

Regards

Daniel

[Daniel Blanc]

I have spied the request header with the chrome developper tool. The cookies have completly disapeared from the header when the xsiframe linker is enabled.

I have tried the same with a gwt project without GWTP and the cookies remains present with the xsiframe linker

This seems to show that GWTP+xsiframe kill the cookies  ...

[Richard Wallis]

Hi Daniel,

Are you also using a .html file in your big application?  Might be being served as static and the cookie filter isn't intercepting it?

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Blanc]

Oups sorry Richard, I missed your message

I do not understand your point. Security cookie works perfectly well but fails as soon as I use xsiframe linker. 

[Richard Wallis]

Ok I'm not sure if this is your issue but if the first visit to your site is to a .html file then the filter will be bypassed and the cookie won't be set.

But if the first visit is to some other location eg "/" then the cookie will be set and the Security cookie will work correctly. So .html files will work after that.

Just seemed like that might be causing it to sometimes work and sometimes not.

[Daniel Blanc]

Thanks for the explanation. I will have a look at the detailed sequence next time I look at it, but I agree with you, there is low probability it is the issue.

Some details :

I have only the html file containing the nocache.js call.

The .htm files are excluded from the static files in the appengine-web.xml

On top of that, I insured to have a non secure rpc call at the bootstrap of the application (in case it could help to setup the Security Cookie, but without success)

Regards

Daniel

[Daniel Blanc]

Hi Richard,

your insight was right, it is a problem of filter bypass. Although, I do not know yet how to solve it.

My appengine-web.xml filter setting is :

<static-files>

<include path="**" />

<include path="**.nocache.*" expiration="0s" />

<include path="**.cache.*" expiration="365d" />

<exclude path="**.gwt.rpc" />

<exclude path="/**.html" />

</static-files>

I spied the "doFilter" method of FilterDefinition.class in both cases, an I observed that when I access the site with  http://localhost:8080/ :

- without xsiframe, the path seen by the filter is "/project/E4FE468A7FC7ACD68E40E5971242B6C0.cache.html". That path matches the rule <exclude path="/**.html" /> and the cookie is correctly set.

- with xsiframe, the path seen by the filter is "/" and the cookie is never set, but if I use http://localhost:8080/Project.html, the cookie is correctly set.

What looks strange to me is why the generated path is different with and without xsiframe ? and why it is not the welcome file path defined in web.xml that is seen ? (Project.html) 

Last but not least, I do not know yet how to solve it. I tried a couple of static files rules without success.

Any suggestion is welcome

Daniel

[Richard Wallis]

Yes, I've run into this problem before, I don't think it's possible to set a .html file not to be static.

They way to solve it is to rename the file to .jsp.

[Daniel Blanc]

I've probably missed something, I do not understand 

I always have "/" seen by the filter whatever the file type and the cookie is never set