I have. While someone breaks the bad news to you, a techie in another room removes all of your permissions from the business’ systems. They don’t want you Falling Down and setting fire to the organisation’s data on your way out the door. Fair enough.
So back to Cloud app development…
If someone gets the boot, and they sprint back to their desk and click some buttons, does our Cloud app have to deny them access? I mean before they’ve even refreshed the web page?
Communication between our JavaScript client and our Cloud service
Our app produces a web panel containing a form. As the user interacts with the form, HTTP requests are sent back to our cloud service directly. Those requests don’t go via Jira. We use a simple page token mechanism to preserve the authentication context.
The problem
Since we don’t ask Jira on each and every interaction if the user is still authorised to do whatever, it’s possible they could get away with a few interactions before either a) they refresh the web page; or b) our page token expires.
My question to you, dear reader
What should we do here? Should we check with Jira on each HTTP interaction to see if the user is still authorised? Ugh. That would impact responsiveness. Should we merely continue to expire page tokens after a short time? What timeout duration would you recommend?
We thought about the same topic a while ago because we had a bug bounty submission about this use case. We’re using a JWT session token for all our requests and reduced this timeout with 5 minutes. It was way higher before.
If an employee really wants do some harm, he could have established some backdoors, taken the data or similar already the days and years before. So I don’t think 5 minutes really change something here. However, I’m also interested in other opinions.
What a good way to explain this security issue.
We have several endpoints that should be used only by Jira Administrators. To prevent broken authentication and privilege escalation, we are verifying the user permission on each request.
I would prefer not to do it to not impact our response times, but I didn’t notice any relevant impact on responsiveness. Here is another article about it.
We use a white list approach. As you, we didn’t want to impact responsiveness by calling Jira to validate access on every call; especially since response time is important in our case. Also, we didn’t want to set a very short expiration time on the JWT token because we believe that a common use case for us is a user keeping Jira opened and interacting with our App without reloading Jira for some time.
So when a user accesses an issue/page from Jira, we create a token that we keep on the server. Since Jira properly controls the access to the page, we know that the user is rightfully authenticated. That token has an expiration time and is refreshed every time the user reloads the page.
When someone uses the API to contact our server, assuming that the JWT is not expired, we double check if the issue/page he’s trying to access has a valid token associated to him. If not we prevent access.
This allowed us to go around Broken Authentication of private Jira Projects without actually calling the Jira permission API every single time.
You can then use a webhook to be notified of user changes in Jira and revoke the tokens associated to the user. So, if the company removed the user from Jira, you are notified and remove the token from the white list.
That’s a good solution to at least part of the problem, certainly the just-got-fired part. It doesn’t cover changes to issue/project permissions, but there’s value in reducing the vulnerability scope.
We don’t use our own tokens, we simply call AP.context.getToken() before each request. That way, we let Atlassian decide how to deal with this problem. If Atlassian does not refresh the token automatically for each AP.context.getToken() request, but only refreshes once the token expires, that should be a sign as to how Atlassian feels this right?
Dealing with the falling down firestorm is, in a way, a straightforward need to allow for rollback, or as @remie says a good candidate for the authentication checking to be delegated upward to Atlassian.
Data egress is trickier to handle with already established authenticated sessions. Requiring getting updated context tokens for each read is an overhead to test, and rather nullifies the point of them.
We’ve been looking at how to handle this from the other perspective where access to Jira is via SSO from our systems and propagating user rights removal is not straightforward for the same reasons. A read session of an unauthorised user has been known to persist for some time after deactivation depending on the UI context changes.
Just don’t be a jerk when firing people. If you’re still worried, then have security escort them out without allowing them access to their computer. If they are working remote, then have IT security disconnect them from the VPN before they are notified.
Minus the jerk statement (too subjective) I second this approach. This is a low tech, low cost solution which works in the government sector, so it should work in the private sector just as well.
Just to add more fuel to the fire, the longevity of app-generated session tokens is also an issue in relation to user logout. Since Jira Cloud does not provide a logout webhook, our apps don’t know that the user has logged out, and therefore don’t know to invalidate our own session tokens. Unless we re-authenticate the user on each and every interaction they have with our REST APIs - slow!
But I think this is also a problem of general knowledge about how to deal with sessions within the developer community. JWT tokens were never designed to be long-lived and even with stateful web servers, it was always recommended to re-authenticate the user.
For some reason, the developer community has abused JWT as some sort of holy grail to avoid server round-trips, adding sensitive information to the claim and stretching the expiration timeout to extreme lengths. For me, this is not an Atlassian problem, but a developer problem.
