要約

Jira presents an XSRF Security Token Missing message several times daily when performing routine operations.

Other symptoms with the same root cause and resolutions are "auto logout" or sessions expiring unexpectedly.

環境

Jira Core 8.4.0 or later.

Previous versions may also benefit from the diagnosis and resolutions listed here, but Jira 8.4 shipped more strict session validations that may cause this behavior more often.

診断

The error is not easily reproducible and occurs randomly, affecting several users on several projects and operations.

This XSRF error occurs for several reasons. Each is mapped as the same number on Cause and its corresponding Resolution. 

The occurrence of this error might've started or increased after upgrading from a previous version of Jira to any more recent than 8.4.0.  In some cases, the below exception is noticed in the Jira log

Caused by: java.io.IOException: Invalid Form Data, no boundary encountered.

To diagnose the issue:

1. Generate a HAR file.
2. Open the HAR file in HAR viewer and look for the first request "Headers" output of XNODE-ID and JSESSIONID. For example: 
   1. First Request
      • 
   2. Header output
      • 
3. Look at the last request "Headers" output of XNODE-ID and JSESSIONID. For example: 
   1. Last Request
      • 
   2. Header output
      • 
4. Please confirm both first and last requests of XNODE-ID and JSESSIONID are the same. 
   1. IF XNODE-ID is different, you are affected by Cause 1.
   2. IF JSESSIONID is not the same, you are affected by Cause 7.

Enable DEBUG on the package com.atlassian.jira.security.xsrf & http dump.

原因

Jira 8.4 packed a security fix to improve the Cross-Site Request Forgery (CSRF) protection:

JRASERVER-69791 - 課題詳細を取得中... ステータス

This improvement adds a security check that compares the XSRF token from the client with the value previously stored in Jira's server-side session. This means the XSRF check is more restrictive now, and some network setups (proxies, firewalls, load balancers) that used to work before Jira 8.4 might result in such XSRF errors now.

1) Jira DataCenter node switching

Jira DC requires "session stickiness" to function properly. If the load balancer is not correctly configured, more than one node will answer browser requests during the same sessions, and this is not expected. 

2) Other Atlassian applications on different contexts

You may have Jira and Confluence under the same domain and only routed through a different context, like:

yourcompany.com/Jira
yourcompany.com/confluence

If Jira's session timeout is short, this may incur XSRF errors when requests are performed after the session's been invalidated.

3) Short session timeout

If Jira's session timeout is short, this may incur XSRF errors when requests are performed after the session's been invalidated.

4) Sessions prematurely terminated

Jira has a mechanism to identify inactive bot sessions and terminate them to free resources ASAP, yet this may cause false-positive session terminations and XSRF errors.

This is aggravated if using third-party authentication but is not restricted to it.

5) Unfixed issues

Since Jira 8.4, several XSRF improvements have been published and may fix this XSRF behavior for your particular scenario.

6) JRASERVER-69054 and filter-mapping

One of the fixes was shipped in Jira 8.12 and has a workaround that can be implemented in previous versions, from 8.4.x to 8.11.x.

7) JSESSIONID cookie being modified by reverse-proxy or load balancer

Generating a HAR file during a couple of usual operations will provide the JSESSIONID cookie; there are settings on the reverse proxy or load balancer that might modify the cookie. There are several ways this can be disruptive to Jira functionality.  Bypassing the proxy and accessing the instance directly is also a good way of determining if the load balancer or proxy is the cause.

8) A browser extension is removing cookies

Some users or organizations will install browser extensions that remove cookies periodically. This can disrupt Jira's functionality and be tested quite easily by disabling extensions or using Jira in Incognito Mode.

9) Missing /work folder in the root of <jira-installation> directory, or the folder exists, but the user running Jira does not have sufficient read and write permission to access it

If you are observing the XSRF security token missing error only when uploading a new logo or when creating Jira issues (with attachments) in a new tab, then the KB article XSRF Security Token Missing ERROR while uploading Jira Logo applies.

10) Action performed by a 3rd party app

Some issue actions provided by 3rd party apps can cause XSRF errors. For example, uploading XML execution results with the Xray app can cause an XSRF error due to some required fields missing or not having their values set.

11) Form Data was removed by the Proxy (F5)

ソリューション

1) Jira DataCenter node switching

Please ensure that the Jira load balancer has session stickiness (or node affinity) enabled and that the cookie is configured to use JSESSIONID. 

Please see the load balancer example that shows the type of Jira DC sticky sessions that are supported:

• Jira Data Center ロード バランサの例

If you use an F5 load balancer for Jira, please configure F5 to use sticky sessions with JSESSIONID cookies. In the F5 configuration, you can review the cookies configuration as described below:

• Configuring HTTP Load Balancing with Cookie Persistence

2) Other Atlassian applications on different contexts

Make sure your proxy and load balancer work with the JSESSIONID cookie.

Other load-balancing cookies (like AWS's native) may not work with context paths, and you'll get XSRF errors whenever the browser makes requests between Jira and other Atlassian products like Confluence, BitBucket, and Bamboo.

3) Short session timeout

Increase the session timeout on both web.xml as described in this changing the session timeout KB article.

4) Sessions prematurely terminated

Turn off the Atlassian Bot Session Killer app as described in this KB on early session termination.

5) Unfixed issues

Upgrade Jira to benefit from the following fixes, to name a few.

Jira 8.5.5:

JSWSERVER-20347 - Getting issue details... STATUS

Jira 8.5.6:

JRASERVER-70574 - 課題詳細を取得中... ステータス

Jira 8.12.0:

JRASERVER-69054 - 課題詳細を取得中... ステータス

6) JRASERVER-69054 and filter-mapping

Until the upgrade to Jira 8.12 or later, the following workaround can be implemented if none of the previous helped fix the XSRF issue:

The solution to the above bug is to map the 'xsrf-token-addition' filter directly above the 'filter-plugin-dispatcher-before-decoration-request' filter in the $JIRA_INSTALL_DIR/atlassian-jira/WEB-INF/web.xml. All you need to do is add the following lines to the web.xml:

<!-- XSRF filter needs to be before any other filter that can send the first byte to the client,
        e.g. a dispatcher filter to avoid issues with Flush Head Early and BigPipe
         XSRF filter cannot add any headers/cookies to the already flushed responses
         More info: YET-70 -->
    <filter-mapping>
       <filter-name>xsrf-token-addition</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>

Paste them immediately above this section (roughly line 660 in the default web.xml):

    <filter-mapping>
        <filter-name>filter-plugin-dispatcher-before-decoration-request</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>

7) JSESSIONID cookie being modified by reverse-proxy or load balancer

Verify the load balancer or reverse-proxy settings and documentation to ensure no disruptive modifications are done to JSESSION cookies. For example: ProxyPassReverseCookiePath or ProxyPassReverseCookieDomain in httpd.

8) A browser extension is removing cookies

Confirm that you don't have a browser extension installed that removes cookies by turning off all extensions or navigating Jira using Incognito Mode. If you have a browser extension installed with this behavior, you may need to add an exception for Jira's cookies or disable the extension.

9) Missing /work folder in the root of <jira-installation> directory, or the folder exists, but the user running Jira does not have sufficient read and write permission to access it

Check the diagnosis and resolution steps from the KB article XSRF Security Token Missing ERROR while uploading Jira Logo

10) Action performed by a 3rd party app

Please raise a vendor support request so they can analyze the problem with the action caused by their 3rd party app.

11) Check with the Proxy/LB team

for F5 LB, The protocol profile (Client): TCP and HTTP profile (Client): http could be reviewed.

回避策

Jira 8.5.3 or later

If none of the previous solutions worked out, you might enable this feature flag (aka dark-feature) to revert to the pre-8.4 XSRF checking method:

com.atlassian.jira.security.xsrf.session.token.disabled

Jira 8.5.2 or earlier

You can temporarily turn off XSRF checks by adding the following to the jira-config.properties, following the instructions on Edit the jira-config.properties file in Jira server.

jira.xsrf.enabled=false

We suggest that you resort to this workaround only temporarily while you work on upgrading Jira to a version where this issue's been fixed for your scenario or that you can apply the feature flag workaround instead.

Related KB articles

Here's a collection of other KB articles related to this missing XSRF Security Token error. Please browse them if the advice in this article didn't prove helpful:

• Associating Custom Field to Screen Results in XSRF Security Token Missing error

• Bulk editing more than 10000 issues will result in XSRF Security Token Missing

• Blank Page or Missing XSRF Token when CSV Import

• Changing Workflow Scheme Results in XSRF Token Error