Possible security access bug? User able to change their own attributes


This is my first time in this group and I am new to Keycloak administration so I apologize in advance if this is a silly question.

I’ve come across and possible security access vulnerability where you can change a user’s attribute with the own token credential but as far as I can tell the user is not allowed to change their own attributes when they log on to the console as themselves.

Here are the steps I took to recreate this issue:
1 . Instantiate a keycloak server with image 7.0.1 (I’ve been told this works on the newest version as well)
2 . Go to clients and create a new openid-connect client (test-client). The configuration of the newly created client is set to default i.e. Standard Flow Enabled: true, Direct Access Grants Enabled: true, Access Type: public
3 . Go to users and create a new user (test) with password ‘1234’
4 . use the above created client to obtain a token for the above user

token=$(curl --noproxy ‘*’ -k -d “client_id=test-client” -d “username=test” -d “password=1234” -d “grant_type=password” -d “client_secret=” “https://localhost:8443/auth/realms/master/protocol/openid-connect/token” | jq .“access_token” | tr -d ‘"’)

5 . Use above token for user test and change his user attributes with below command
curl --noproxy ‘*’ -X POST -k -H “Authorization: Bearer ${token}” -H “Content-Type: application/json” -d ‘{“attributes”: {“a1”:[“1”],“a2”:[“2”],“a3”: [“3”],“a4”:[“4”]}}’ https://localhost:8443/auth/realms/master/account/

This is done when “account_api – Account Management REST API” and “account2 – New Account Management Console” are disabled as they are by default.

Doing the above steps 1-5 this might have some security impact, since in the user attributes the administrator might have configured sensitive information and the user should not alter those.
Moreover, ldap federated users have in the attributes section sensitive information such as userId, HomeDirectory,LoginShell etc.
So, a malicious user can explore this and change his userID and therefore pretend to be someone else.

I would appreciate any advice on where this issue might be coming from, or if it even is an issue I could just be mistaken.

It’s interesting that nobody has replied on it, but I’ve noticed a similar security issue which is related to the same mechanism.

A user which has access to the account console can completely control their own attributes and can even create ones that were never there, just by changing the input to a different id.
So for instance:

   <input type="text" id="user.attributes.additionalRoles" name="user.attributes.additionalRoles"

After a submit of the form this will generate or update the attribute key and value “additionalRoles”, just by changing it on the client side in the browser! There is not validation/protection to counter this what so ever.

I wonder what the KeyCloak team has to say about this.

It has always been true that a user has the permission to change/create his own attributes. While it is tempting to use the user attribute map to store information about the user that they either shouldn’t see or be able to edit, this has not been the default functionality since the beginning, nor has it been recommended for the use case.

To allow profile permissions and other functionality, the “Declarative User Profile” feature was added a few versions ago. It is currently in the “technology preview” state, but I have used it in a few projects, and it is working fine. Documentation is here: Server Administration Guide

Define specific permissions for viewing and editing user attributes, making possible to adhere to strong privacy requirements where some attributes can not be seen or be changed by third-parties (including administrators)

I understand that you shouldn’t use attributes for that, my example was just a bit extreme. But in our case we had the idea to give the user the ability to add/update their phone number (which we then would use for some other processes), but by doing that, we can’t really rely on it in the way we should be able to.

But thank you for this insight in the “Declarative User Profile” feature, that is basically exactly what we are looking for.