Cross Site Request Forgery (CSRF) protection changes in Atlassian REST

Recent changes in Atlassian REST mean that some browser requests may be blocked because the origin of the request is not trusted.

A REST request is subject to origin CSRF checks if the following conditions are met:

1. the request is a POST request (the http verb is POST)
2. the request is from a known browser
3. the request is sending a content-type which is not one of the following
   1. application/x-www-form-urlencoded
   2. multipart/form-data
   3. text/plain
   4. empty or not specified

When an untrusted origin attempts to send a request that meets the conditions specified above it will be blocked and a log entry similar to the following should be present in your application’s log file:

2015-09-01 17:25:46.530585500 2015-09-01 07:25:46,530 ajp-nio-127.0.0.104-8009-exec-23 WARN anonymous 1045x1465x1 sibktb 127.0.0.1 /rest/auth/latest/session [c.a.p.r.c.security.jersey.XsrfResourceFilter] Additional XSRF checks failed for request: https://example.domain/rest/auth/latest/session , origin: https://another-origin.domain , referrer: null , credentials in request: true , allowed via CORS: false}}


Symptoms

The following symptoms have been experienced and resolved by fixing the configuration:

• update an add on, including the Universal Plugin Manager,  from the Atlassian marketplace

How does the CSRF origin protection work?

The CSRF origin protection works by comparing the origin of incoming requests via the origin and referer headers. In simple terms it checks that the origin of a request is in the same origin as the application itself or if the request origin is trusted by the application.

How to fix it?

This usually happens due to Tomcat proxy configuration issues.

If an Atlassian application is run behind a proxy and you are encountering issues with the origin based CSRF protection then please check the following parameters are configured in the server.xml:

• the configured proxyName matches the hostname that the application is accessed on.
• the configured proxyPort matches the port that the application is accessed on.
• the configured scheme matches the scheme that the application is accessed with.

For example, if JIRA is running behind apache and the url to access JIRA is https://example.domain/ then the correct proxy settings are the following

• proxyName=”example.domain”
• proxyPort=”443″
• scheme=”https”

For the same example, if there is a misconfiguration on the server.xml and the parameters are configured pointing to HTTP, you’d reproduce this UPM issue:

• proxyName=”example.domain”
• proxyPort=”80″
• scheme=”http”

Postman extension workaround

If you wish to use the Postman browser extension then you may need to install the Postman Interceptor browser extension. The following steps sets the Origin header to be in the same origin as