Have you ever tried to attach a file or image to a Jira issue, and got the error Jira could not attach the file as there was a missing token. Please try attaching the file again. ? This commonly happens when:
- You are viewing a Jira issue
- You leave your computer for over 5 hours --or-- in another tab you log out and back in to Jira.
- You return to the issue, and without refreshing the page try to attach a file or image to the issue.
It also happens if you click the 'Create' button to create a new issue, and on the 'Attachment' field try to upload an attachment.
Background: CSRF attacks
The 'missing token' in question is a CSRF token used to prevent CSRF (cross site request forgery) attacks.
An example of a CSRF attack would be as follows. An attacker creates a HTML page at https://hax0rs.com/kittens containing:
<img src="https://jira.yourcompany.com/secure/admin/user/AddUser.jspa?email=evil%hax0rs.com&fullname=Mr+HaX0r&username=hacker&password=fake123&selectedApplications=jira-software&Create=Create+user" width="0" height="0" border="0">
If you visit a site containing that HTML, your browser will blindly request that HTTP URL to the 'image', and (if you are a logged-in Jira admin) create a new hacker Jira account!
Why did Jira, upon receiving that AddUser.jspa HTTP request, trust the sender? Because your browser identified the request as "coming from you" by including a identifying JSESSIONID cookie, as it does for all HTTP requests to jira.yourcompany.com.
Jira's defense against CSRF is to generate a random bit of text (the 'CSRF token') just for you when you log in, and embed it in every HTML form that changes server state (like adding users). The field is called atl_token:
Then when receiving a request to AddUser.jspa (for example), Jira checks that the atl_token param value is correct before performing the operation. The CSRF token value is a secret known only to Jira and your browser, and changes after every login or session expiry (5h of inactivity). An attacker won't know the correct atl_token parameter to include in their forged URL.
This is known in the literature as the synchronizer token pattern.
CSRF tokens in Jira
While you are actively using Jira, Jira maintains a 'session' for you. A session is just a handful of key:value pairs. Incidentally, if you are a Jira administator you can see your session's attributes by dropping sessionattributes.jsp into your atlassian-jira/secure/ directory, and hitting the /secure/sessionattribute.jsp URL:
The session attribute we care about here is atlassian.xsrf.token (Jira uses 'XSRF' as a synonym for CSRF). When Jira generates the HTML for pages like AddUser.jspa it includes this atlassian.xsrf.token value as a hidden atl_token parameter:
Your Jira 'session' doesn't last forever. The default session timeout is 5 hours (or 18000 minutes, the 'Max Inactive Interval' in the JSP output). When your session times out, or when you explicitly log out and back in again, your session is lost and so is your XSRF token . Next time you log in you'll get a new randomly generated atlassian.xsrf.token.
An SRF token is a secret bit of text known only to the Jira server and your browser. In your browser you can see the same XSRF token in a cookie by clicking on the padlock icon to the left of the URL:
Jira's atlassian.xsrf.token cookie
What's happening is as follows. When you are actively using Jira, the Jira server keeps a 'session' for you,
Your browser must include the XSRF token with every request, usually as a cookie. If a request comes without a matching XSRF token, Jira will assume that the request did not come from a trusted source, and will respond with an error.
This XSRF token stays the same for the duration of your session, which is 5 hours by default (5h = 18000 minutes in the Max Inactive Interval session attribute). After 5 hours of inactivity, or if you log out and back in again, you get a new session and a new XSRF token.
XSRF in cookies!?
I have to say, I do not understand how Jira's CSRF protection works. CSRF is an attack where, e.g. The whole point of a CSRF token is that it isn't just another cookie that the browser blindly attaches to a request. The presence of a CSRF token in a request is meant to signify that
When atlassian.xsrf.token cookie isn't used
