Issues after enabling CSRF Prevention Filter

NNma · May 8, 2019, 7:15pm

Hi all,

I upgraded camunda from 7.9.0 to 7.10.0 version. I followed instructions from this page https://docs.camunda.org/manual/latest/update/minor/79-to-710/ and did the following steps for upgrade:

Since I’m using Spring Boot I checked compatibility versions from this page https://docs.camunda.org/manual/latest/user-guide/spring-boot-integration/version-compatibility/
and update camunda dependencies

<camunda.version>7.10.0</camunda.version>
<camunda.spring.boot.starter.version>3.1.0</camunda.spring.boot.starter.version>

Spring Boot version is 2.0.3.RELEASE

Execute all SQL scripts related to camunda 7.10.0 upgrade

Upgrade went well and I was able to start camunda application. The main reason for upgrading to 7.10.0 is Prevention of Cross-Site-Request-Forgery attacks.
This documentation page https://docs.camunda.org/manual/latest/update/minor/79-to-710/#csrf-prevention-in-the-webapps says that if we want to use CSRF
security enhancement we need to enable “CsrfPreventionFilter”, so I enable it with this code below

        @Bean
        public CsrfPreventionFilter csrfPreventionFilter() {
          CsrfPreventionFilter csrfPreventionFilter = new CsrfPreventionFilter();
          csrfPreventionFilter
            .setEntryPoints("/api/engine/engine/default/history/task/count, /api/engine/engine/default/history/variable/count");

          return csrfPreventionFilter;
        }

With filter enabled, I cannot create CSRF attack, if I try I get following error
(type=Forbidden, status=403). CSRFPreventionFilter: Token provided via HTTP Header is absent/empty.

And this is all great camunda version 7.10.0 solves CSRF issues, but with CsrfPreventionFilter enabled lot of other issues occurred
I cannot:

create a new user in camunda (“status”:403,“error”:“Forbidden”,“message”:“CSRFPreventionFilter: Invalid HTTP Header Token.”)
delete user (“status”:403,“error”:“Forbidden”,“message”:“CSRFPreventionFilter: Invalid HTTP Header Token.”)
logout user (“status”:403,“error”:“Forbidden”,“message”:“CSRFPreventionFilter: Invalid HTTP Header Token.”)
Open Tasklist (same error, also in console I get " <- Unsuccessful HTTP response")

If I disable CsrfPreventionFilter everything works fine, but the purpose of upgrading is to solve CSRF issues.
After doing some research and debugging CsrfPreventionFilter I found the following:

When I open login page => http://localhost:8090/app/welcome/default/#/login I get two cookies JSESSIONID and XSRF-TOKEN.
And by debugging I found out that for current session CSRF token is generated and the value of that token is set as a session attribute => CAMUNDA_CSRF_TOKEN and also same value is set for the response header => X-XSRF-TOKEN.
Then when I log in and get to welcome page => http://localhost:8090/app/welcome/default/#/welcome I get new JSESSIONID,
and since old session is invalidated and the new session doesn’t have CAMUNDA_CSRF_TOKEN attribute, new CSRF token is generated and set as a value for CAMUNDA_CSRF_TOKEN and also for X-XSRF-TOKEN response header.
In the browser, I can now see that I have two XSRF-TOKEN cookies one that I got on the login page and one that I got when I access to welcome page.

Now with every subsequent request, I can see that X-XSRF-TOKEN header is sent with old outdated value, so in request headers
value of XSRF-TOKEN from the cookie and X-XSRF-TOKEN differs and because of this when CSRF token is validated, there is a mismatch between token from header and token from the session. And the result of this is “Invalid HTTP Header Token.”
Also, just to be sure that this is the cause of problems I did the following:
Go to welcome page and deliberately delete old XSRF-TOKEN cookie that I got on the login page and for the new one I replace path attribute of cookie to be same as
in JSESSIONID cookie, by doing this I was able to trick the browser to send a right cookie, and as a result, everything works fine and all above-mentioned problems no longer exist.

Is there something that I’m missing in upgrade steps or does anyone have a similar or same problem?
It seems to me that on backend everything works fine but for some reason from frontend side, requests are sent with wrong X-XSRF-TOKEN header.

Thanks in advance.

Ingo_Richtsmeier · May 9, 2019, 8:56am

Hi @NNma,

after upgrading to 7.10, you should use the REST api from the camunda-bpm-spring-boot-starter-rest to interact with engine from any rest client except the web app.

A workaround to overcome the XSRF-TOKEN issue is to login to the webapp and do a GET request first. Then you can do POST request with the cookies handling the XSRF-stuff.

But the first approach is sustainable.

Hope this helps, Ingo

NNma · May 9, 2019, 3:50pm

Hi @Ingo_Richtsmeier thank you for your answer

I’m trying to understand your first suggested approach.
Currently in my dependencies I have

camunda-bpm-spring-boot-starter-webapp which will enable the Web Applications
I don’t have
camunda-bpm-spring-boot-starter-rest
I’m not using REST API and instead I’m using JAVA API to interact with engine

Is there any other approach in this case where REST API is not used?

Ingo_Richtsmeier · May 10, 2019, 6:27am

Hi @NNma,

having a closer look to your descrption and the docs I found:

targetOrigin Application expected deployment domain: the domain name through which the webapps are accessed. If nothing is set, the Same Origin with Standard Headers verification is not performed.

I can’t see a targetOrigin in your filter implementation. If you don’t need it, just drop your filter configuration. (maybe you configured two filters which confuses your client?)

Hope this helps, Ingo

NNma · May 10, 2019, 7:30am

Hi @Ingo_Richtsmeier

here Update from 7.9 to 7.10 | docs.camunda.org it says that

If you want to make use of the newly introduced security enhancement, please make sure to enable the CsrfPreventionFilter when migrating to 7.10 by adjusting the web.xml file of Camunda BPM Webapps.

In my case since I’m using Spring Boot I enabled it by registering CsrfPreventionFilter Bean.

I tried to drop the filter but then XSRF-TOKEN isn’t even created at all, and I can easily create CSRF attack. Same errors happen if I set targetOrigin in my filter.

Yesterday I cloned this repo camunda-bpm-examples/spring-boot-starter/example-webapp at 7.10 · camunda/camunda-bpm-examples · GitHub with tag 7.10 hoping that maybe clean state will make a difference but I found out that even with starting from 7.10 version same errors are present. Just by enabling CsrfPreventionFilter everything goes wrong.
What do you think, do I have any other options here or to try with some workaround?

And thank you again for your support

nikola.koevski · May 10, 2019, 2:57pm

Hi @NNma,

We are aware of the problem of the CSRF Prevention Filter not working properly with the Camunda Spring Boot Starter. The reason is that the Spring Boot Starter Webapps use the “root” context path, which leads to browsers setting the wrong Cookie path for the XSRF-TOKEN Cookie. The fix for the problem has already been done, and will be available with the next release.

However, as a workaround/quick-fix, you can set the context path to something like “/camunda” in you application.properties file. The property is server.servlet.context-path.

I hope this helps.

Best,
Nikola

NNma · May 13, 2019, 5:44am

Hi @nikola.koevski

Thank you for the info.
Setting server.servlet.context-path in application.properties file, solves this issue.

romankh3 · August 1, 2019, 7:44am

Hello, @nikola.koevski!
I have the same problem, I can’t enable CSRF protection for 7.10 version. Tel me please, What Can I do with it? I can’t change context-path.

And Can you send the link to the jira-issue where this problem will be solved?

nikola.koevski · August 2, 2019, 9:12am

Hi @romankh3,

The Jira ticket is a security fix, so it won’t be visible to you. However, there is a security notice here that lists the Starter versions that were fixed: https://docs.camunda.org/security/notices/#notice-12

You should also be aware of the warning here: https://docs.camunda.org/manual/latest/user-guide/spring-boot-integration/webapps/

Best,
Nikola

ChandruM · February 26, 2020, 10:21am

Did you still had the CsrfPreventionFilter in your application? I am facing the same issue.

Arne_K · January 29, 2024, 12:40pm

I had the same error message but a different cause.

If you run your application in a kubernetes environment with multiple pods, you might have to enable sticky sessions in your ingress. This fixed the issue for me. The error message is very misleading and therefore this is not the obvious thing to do.

I am running Canunda 7.20.1-ee in Spring Boot 3.1.

I hope this helps someone with a similar problem.
Cheers,
Arne

system · January 30, 2024, 11:43am