Missing Function Level Access Control vulnerability in ac-express and ac-spring-boot

I am trying to figure out how would you fix Missing Function Level Access Control vulnerabilitiy in the framework. I think this is the most basic and common vulnerability that most apps on the marketplace are vulnerable to.

Basically, all endpoints in ac-express and ac-spring-boot are authenticated but not authorized. By default any user who is authenticated in Jira is able to call any endpoint in the application. It also applies to guest users (not logged in) in publicly available Customer Portals!!
This can be serious depending on the scope of the application and the data it provides through its endpoints. A basic example is administrative pages with read / write endpoints that other users should not have access to.

Yesterday, I read a comment pointing me to, what I think would be the best direction.

I have already left a comment on ACSPRING-88

Description of the ticket:
The JavaScript API method API.context.getToken() returns a JWT token with an extended context claim containing identifiers of domain objects in context of the current request. Expose this claim in AtlassianHostUser.
This is already in progress. I have not checked if a similar ticket was created for ACE

My idea was, would it be possible for the JWT context to also contain more information about user permissions or roles?

In fact, in most scenarios it would be enough to distinguish 3 roles that already exists when you use conditions to display a page module, i.e. user_is_admin, user_is_project_admin, user_is_logged_in, others.

If those basic roles would be available in JWT context claim and if both frameworks would support decoding this additional claim and exposing it in User objects used in frameworks, then implementing a basic authorization in all apps on the marketplace would be a breeze.

What do you think? @mhart @epehrson

4 Likes

It would be very interesting to see this added to the token.

Currently I have implemented a workaround that collects the current user permissions using the /rest/api/3/mypermissions endpoint so that the app can validate that only admins have access to the admin pages of the app, but this generates a lot of load that can now only be avoided when implementing a cache of the permissions. A solution without a cache would be better.