How to detect permission change on an issue (e.g. webhook)

Jira Development Jira Cloud
1

Hi folks,
Is there a way to detect the change of permissions on an issue?
I cannot find the specific webhook here:

https://developer.atlassian.com/cloud/jira/software/webhooks/

In our app we allow different UI/APIs accordingly to the user permission on the issue.

We are looking for an efficient way (i.e. not polling) to detect if the permission change in order to react accordingly (e.g. invalidate a session if the user has no enough permission).

TIA

2

Hi @sax,

I’m not aware of any permission change events that you would need to solve this efficiently. I take it that you’d like to proactively perform some task(s) on certain permission mutations? The community must have come across this problem before so maybe there are some design patterns that circumvent/mitigate the issue that others can share?

Regards,
Dugald

3

Hi Dugald,
Just to better clarify, the scenario reported by a security researcher is the following:

  • the user has edit permission on the Jira issue.
  • on opening, the app is piggybacking the Jira Project permission in order to allow edit role on the app project
  • permission changes and the user has no more access to the issue.
  • app should invalidate the user session on the app project showing some warning and freezing the UI.

The check on user permission (calling Jira API) is done on the opening and closing of the app project, but (for performance reason) not on every edit of the app project.

Any idea how to solve this without calling Jira API in polling?

4

Hi @sax,

Just to circle back on this one as it’s been a couple of weeks. Currently the JWT that gets passed from the connect iframe through to the app has a 15 minute expiry window.
If a user permission changes within that window, then the access to the app can still persist for up to 15 minutes.

This is currently a known risk (albeit not an ideal one). A 15-minute expiry in terms of risk is quite low in terms of exploitation - the window is very small. It’s similar to other risks around session management and eventual consistency windows.
Ecosystem Security do want to review this risk in the future - but right now it’s not the highest risk review we have in our queue.

Once a JWT has passed its exp, any requests with that token should have a 401 returned - so hopefully that should give some guidance on how long an Authorization cache can be reasonably held before there’s additional risk of permission changes.

I hope that helps!

Cheers,
Matt

1 Like