Issue with CSRF Prevention filter of camunda-bpm-wildfly-7.10.0

Camunda 7 Topics Discussion & Questions
,
1

I currently installing camunda-bpm-wildfly-7.10.0 on Wildfly and run into a user session problem: The session is lost e.g at the XHR POST request invoked by pressing create user at the add new user form. By help of the Firefox Developer Tools I was able to see the anwer telling about a wrong XSRF-TOKEN.

  • The issue vanishes if I disable the CSRF filter at web.xml. The filter feature seems to be introduced with >=7.9
  • In conjunction with an request header entry X-XSRF-TOKEN, I notice even two additional entries called XSRF-TOKEN in the Cookie:-header entry. Maybe the filter is confused by this.

@Camunda: Please verify this issue. If you provide a bugfix as a classfile for org.camunda.bpm.webapp.impl.security.filter.CsrfPreventionFilter , I may test it.

2

I’m facing a similar issue, after upgrading camunda from 7.9.0 to 7.10.0 version and adding CsrfPreventionFilter filter, I cannot create user, also cannot delete user, or open Tasklist.

@gjaekel Do you still have this issue or you solved it?

3

Dear NNma,
I have still the issue - nobody at Camunda care of the thread, that’s embarrassing!

To allow our project team proceed with it’s work, I disabled the filter section in the web.xml.

greetings
Guido

4

Hi @gjaekel

Maybe this post will help you

5

Dear @NNma,
thank you very much for propagating the solution! I’ll ask the developers if we want to enable CSRF on our 7.10.0, yet.

6

Today I got time to look at it. But re-reading your answer I wonder if this should help because Camunda already is running on the root application context.

7

Hi @gjaekel,

If you want to create a user with the REST API of the web application at http://localhost:8080/camunda/api/… you will run into this issue with the CSRF filter. It’s added for security reasons.

As a workaround you can create the user via REST API at http://localhost:8080/engine-rest/. here you can control the security in the web.xml: https://docs.camunda.org/manual/7.10/reference/rest/overview/authentication/

Or you can keep the CSRF Token, when you do a GET request after login and then do the POST to create a user.

Hope this helps, Ingo

8

I’m not talking about the REST API. At the moment, wee just use the web applications parts. The application is running at the root context of some domain, but without disabling the CSRF filter in the web.xml, one is kicked out at every serious action. If I get some time, I’ll investigate what happens if I define server.servlet.context-path="/" and enable the CSRF filter.

9

Hi @gjaekel,

OK, that’s a different story. Assuming that you mean creating a user with the admin app, I checked it on my computer. It works as expected.

What is your overall setup? Do you run a cluster with a load balancer?

10

This is currently a single instance on a Wildfly farm with an Apache httpd+mod_jk as TLS reverse proxy and load balancer.

11

Hi @gjaekel,

most likely the token get lost somewhere in the load balancer, proxy or Apache httpd configuration.

I had a similar problem with a wrong configuration in the load balancer. Here the admins missed the sticky session configuration. I can assume that your configuration can get tricky.

Hope this helps, Ingo

12

No, that don’ help. The configuration not tricky in any way and proved by more than fifty other application. In addition, as written there’s just a single instance of Camunda running. Therefore, there’s no load balancing but a single route to the used Wildfly instance.

As I wrote, the token is not lost but there are more than one token “cruising around” in the header and the application seems to be confused by this, Until yet, I got not time to figure it out in detail because our developers need a running Camunda. But as soon I have copied the setup to our approval state, I’m free to do some further investigation about the CFRF issue on our test stage.

13