starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

User Can Read Token Material for Other Users When Creating Token #7320

New Issue
Closed
opened 2025-12-29 20:21:42 +01:00 by adam · 10 comments
adam commented 2025-12-29 20:21:42 +01:00
Owner
Copy Link

Originally created by @bryanculver on GitHub (Dec 2, 2022).

Originally assigned to: @arthanson on GitHub.

NetBox version

v3.3.9

Python version

3.8

Steps to Reproduce

  1. Assume a user (user1, with id of 1) has superuser permissions
  2. Have a user (user300) with the add_token permission without constraint, no other permissions (not staff or superuser)
  3. user300 issues themselves a token (either via the UI, or endpoint discussed below)
  4. user300 sends a POST to ://netbox/api/users/tokens/ with the payload below:
    • {"user": 1}
  5. user300 is presented with a token issued for user1, with entire key material data
  6. user300 will only be able to see the key material once, as the key is not associated to their account the query for /api/users/tokens is restricted to their user
  7. If user1 doesn't exist, or does not have superuser permissions, user300 can continue incrementing the user ID until one is found.

Expected Behavior

At the very least user300 with the add_token may be able to create a token for other users who may have a higher privilege than themselves but should not be able to receive the response payload as they do not have view_token permissions.

Ideally, the add_token permission would not be able to allow a user to create tokens for users with higher permissions than themselves.

Observed Behavior

user300 is able to receive the token for user1 and then impersonate that user who may be a superuser, including changing the password.

This can be confirmed in the demo environment.

Originally created by @bryanculver on GitHub (Dec 2, 2022). Originally assigned to: @arthanson on GitHub. ### NetBox version v3.3.9 ### Python version 3.8 ### Steps to Reproduce 1. Assume a user (`user1`, with id of `1`) has superuser permissions 2. Have a user (`user300`) with the `add_token` permission without constraint, no other permissions (not staff or superuser) 3. `user300` issues themselves a token (either via the UI, or endpoint discussed below) 4. `user300` sends a POST to `://netbox/api/users/tokens/` with the payload below: - `{"user": 1}` 5. `user300` is presented with a token issued for `user1`, with entire key material data 6. `user300` will only be able to see the key material once, as the key is not associated to their account the query for `/api/users/tokens` is restricted to their user 7. If `user1` doesn't exist, or does not have superuser permissions, `user300` can continue incrementing the user ID until one is found. ### Expected Behavior At the very least `user300` with the `add_token` may be able to create a token for other users who may have a higher privilege than themselves but should not be able to receive the response payload as they do not have `view_token` permissions. Ideally, the `add_token` permission would not be able to allow a user to create tokens for users with higher permissions than themselves. ### Observed Behavior `user300` is able to receive the token for `user1` and then impersonate that user who may be a superuser, including changing the password. This can be confirmed in the demo environment.
adam added the type: bugstatus: under review labels 2025-12-29 20:21:42 +01:00
adam closed this issue 2025-12-29 20:21:42 +01:00
adam commented 2025-12-29 20:21:43 +01:00
Author
Owner
Copy Link

@bryanculver commented on GitHub (Dec 2, 2022):

This is following up from a disclosure to the security email group which redirected us here.

A user having the add_token permission is less likely if the first install/use of tokens was post Netbox 3.0. Netbox 3.0 no longer requires this permission to be applied to users as a bugfix was implemented to address the perceived expected behavior that users should not need a permission to issue their own tokens (see: https://github.com/netbox-community/netbox/issues/6073). The add_token permission may still exist for users from pre-3.0 installations.

A permission can be scoped to limit a user’s ability to only create tokens owned by themselves (constraint like {"user__username": "theuser"}). Until Netbox 3.3 there was no way for a permission to reference the requesting user when evaluating the permission, which would require a permission created uniquely for each user. No best-practice documentation has been identified showcasing the danger of applying this permission without constraints (current user interface does not highlight this as a potential security concern in the API).

TokenViewSet restricts users from seeing other users tokens unless they are superuser: https://github.com/netbox-community/netbox/blob/v3.3.9/netbox/users/api/views.py#L48-L65 so the create method could be overloaded to apply the same restriction before returning the response to the requested user.

@bryanculver commented on GitHub (Dec 2, 2022): This is following up from a disclosure to the security email group which redirected us here. A user having the `add_token` permission is less likely if the first install/use of tokens was post Netbox 3.0. Netbox 3.0 no longer requires this permission to be applied to users as a bugfix was implemented to address the perceived expected behavior that users should not need a permission to issue their own tokens (see: `https://github.com/netbox-community/netbox/issues/6073`). The `add_token` permission may still exist for users from pre-3.0 installations. A permission can be scoped to limit a user’s ability to only create tokens owned by themselves (constraint like `{"user__username": "theuser"}`). Until Netbox 3.3 there was no way for a permission to reference the requesting user when evaluating the permission, which would require a permission created uniquely for each user. No best-practice documentation has been identified showcasing the danger of applying this permission without constraints (current user interface does not highlight this as a potential security concern in the API). `TokenViewSet` restricts users from seeing other users tokens unless they are superuser: https://github.com/netbox-community/netbox/blob/v3.3.9/netbox/users/api/views.py#L48-L65 so the create method could be overloaded to apply the same restriction before returning the response to the requested user.
adam commented 2025-12-29 20:21:43 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 18, 2022):

At the very least user300 with the add_token may be able to create a token for other users who may have a higher privilege than themselves but should not be able to receive the response payload as they do not have view_token permissions.

But that's the entire purpose of the feature. Some other system having the possibility of provisioning tokens for other users and then either providing the token or using the token to perform actions as the user. I agree that it's an inherently dangerous functionality. As such I'm having a hard time seeing this as a bug, seems more like a feature request to suggest removing the feature.

No best-practice documentation has been identified showcasing the danger of applying this permission without constraints

Are you interested in providing a PR for the updated documentation?

For reference this is what's currently there:

All users can create and manage REST API tokens under the user control panel in the UI. The ability to view, add, change, or delete tokens via the REST API itself is controlled by the relevant model permissions, assigned to users and/or groups in the admin UI. These permissions should be used with great care to avoid accidentally permitting a user to create tokens for other user accounts.

@kkthxbye-code commented on GitHub (Dec 18, 2022): > At the very least user300 with the add_token may be able to create a token for other users who may have a higher privilege than themselves but **should not be able to receive the response payload** as they do not have view_token permissions. But that's the entire purpose of the feature. Some other system having the possibility of provisioning tokens for other users and then either providing the token or using the token to perform actions as the user. I agree that it's an inherently dangerous functionality. As such I'm having a hard time seeing this as a bug, seems more like a feature request to suggest removing the feature. > No best-practice documentation has been identified showcasing the danger of applying this permission without constraints Are you interested in providing a PR for the updated documentation? For reference this is what's currently there: > All users can create and manage REST API tokens under the user control panel in the UI. The ability to view, add, change, or delete tokens via the REST API itself is controlled by the relevant model permissions, assigned to users and/or groups in the admin UI. **These permissions should be used with great care to avoid accidentally permitting a user to create tokens for other user accounts.**
adam commented 2025-12-29 20:21:43 +01:00
Author
Owner
Copy Link

@moonrail commented on GitHub (Jan 13, 2023):

I am a little shocked to be honest, by how easy it is for admins to misuse this edge-case-feature.
I as an admin was not aware of this models CRUD handling being any different from other models and have to say, that I think this "dangerous functionality" - as you've called it yourself - is implemented fairly poorly in comparision to best practices NetBox itself, REST and other applications apply.

I mean - a permission for a non superuser that grants the user the permission to imitate a superuser. At least this has to be a red flag for this feature or lead to a requirement, that superusers can configure it in any way other than create a single object permission definition for token endpoint per user with restriction to allowed users.

Either a seperate endpoint or a seperate permission set would've been valid and avoided any misunderstanding.

Additionally the UI actually currently does require token permissions for users to be able to not only create, but also manage their tokens, see Screenshots below.

Without CRUD on token model:
Screenshot_20230113_154238

With CRUD on token model:
Screenshot_20230113_154348

And here the superuser imitation from a user with token Create-Permission:
Screenshot_20230113_155151

@moonrail commented on GitHub (Jan 13, 2023): I am a little shocked to be honest, by how easy it is for admins to misuse this edge-case-feature. I as an admin was not aware of this models CRUD handling being any different from other models and have to say, that I think this "dangerous functionality" - as you've called it yourself - is implemented fairly poorly in comparision to best practices NetBox itself, REST and other applications apply. I mean - a permission for a non superuser that grants the user the permission to imitate a superuser. At least this has to be a red flag for this feature or lead to a requirement, that superusers can configure it in any way other than create a single object permission definition for token endpoint per user with restriction to allowed users. Either a seperate endpoint or a seperate permission set would've been valid and avoided any misunderstanding. Additionally the UI actually currently does require token permissions for users to be able to not only create, but also manage their tokens, see Screenshots below. Without CRUD on token model: ![Screenshot_20230113_154238](https://user-images.githubusercontent.com/40096303/212349739-66209352-1a5e-408a-a1ed-f7498a66efaf.png) With CRUD on token model: ![Screenshot_20230113_154348](https://user-images.githubusercontent.com/40096303/212349735-9600f4fa-4276-46e4-bd6c-5a7797c9c6d5.png) And here the superuser imitation from a user with token Create-Permission: ![Screenshot_20230113_155151](https://user-images.githubusercontent.com/40096303/212349729-63ea994f-93b6-47d1-b165-ab74eea2509a.png)
adam commented 2025-12-29 20:21:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 13, 2023):

Additionally the UI actually currently does require token permissions for users to be able to not only create, but also manage their tokens, see Screenshots below.

To clarify, users can create tokens for themselves via the UI without the assignment of any specific permissions. This is intentional per #6073/#8436 and noted in the REST API documentation. You're correct in that explicit permission assignment is needed for a user to edit/delete his or her own tokens via the UI, and I've opened #11491 to capture this as a bug.

As @kkthxbye-code points out above, the ability to enable a user to create tokens on behalf of other users is intentional and desired in certain use cases. I'm happy to consider potential safeguards against the accidental misuse of this feature, but so far no specific implementation has been proposed.

@jeremystretch commented on GitHub (Jan 13, 2023): > Additionally the UI actually currently does require token permissions for users to be able to not only create, but also manage their tokens, see Screenshots below. To clarify, users can create tokens for themselves via the UI without the assignment of any specific permissions. This is intentional per #6073/#8436 and noted in the [REST API documentation](https://docs.netbox.dev/en/stable/integrations/rest-api/#tokens). You're correct in that explicit permission assignment _is_ needed for a user to edit/delete his or her own tokens via the UI, and I've opened #11491 to capture this as a bug. As @kkthxbye-code points out above, the ability to enable a user to create tokens on behalf of other users is intentional and desired in certain use cases. I'm happy to consider potential safeguards against the accidental misuse of this feature, but so far no specific implementation has been proposed.
adam commented 2025-12-29 20:21:44 +01:00
Author
Owner
Copy Link

@moonrail commented on GitHub (Jan 13, 2023):

Proposal:

  • by default all token-endpoint usage is restricted to the user of the used API-Token
    • NetBox could apply a simple permission constraint (user__username) to the permission by default
  • if an administrator explicitly defines a constraint on the permission, the default permission constraint is dropped by NetBox and the administrator has to define appropiate constraints to which users this may apply
    • the administrator could just compare any user attribute via regex and a wildcard and achieve the same functionality as the default is now
@moonrail commented on GitHub (Jan 13, 2023): Proposal: - by default all token-endpoint usage is restricted to the user of the used API-Token - NetBox could apply a simple permission constraint (user__username) to the permission by default - if an administrator explicitly defines a constraint on the permission, the default permission constraint is dropped by NetBox and the administrator has to define appropiate constraints to which users this may apply - the administrator could just compare any user attribute via regex and a wildcard and achieve the same functionality as the default is now
adam commented 2025-12-29 20:21:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 13, 2023):

@moonrail we'll have to dig into the implementation details to determine feasibility, but IMO that sounds reasonable. Would you mind opening a feature request to capture this please?

@jeremystretch commented on GitHub (Jan 13, 2023): @moonrail we'll have to dig into the implementation details to determine feasibility, but IMO that sounds reasonable. Would you mind opening a [feature request](https://github.com/netbox-community/netbox/issues/new?assignees=&labels=type%3A+feature&template=feature_request.yaml) to capture this please?
adam commented 2025-12-29 20:21:44 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 13, 2023):

An alternative might be requiring a different action to create tokens for other users, like impersonate or something, like we require the run action for running scripts/reports.

Haven't looked at the current implementation though, so not sure what is more feasible.

@kkthxbye-code commented on GitHub (Jan 13, 2023): An alternative might be requiring a different action to create tokens for other users, like `impersonate` or something, like we require the `run` action for running scripts/reports. Haven't looked at the current implementation though, so not sure what is more feasible.
adam commented 2025-12-29 20:21:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 13, 2023):

@kkthxbye-code ooh I like that idea, it would be a very natural use of custom permission actions.

@jeremystretch commented on GitHub (Jan 13, 2023): @kkthxbye-code ooh I like that idea, it would be a very natural use of custom permission actions.
adam commented 2025-12-29 20:21:45 +01:00
Author
Owner
Copy Link

@moonrail commented on GitHub (Jan 13, 2023):

Separate permission set sounds perfectly fine to me - this also cannot be used by accident, as the Admin UI does not show these as checkboxes.

@moonrail commented on GitHub (Jan 13, 2023): Separate permission set sounds perfectly fine to me - this also cannot be used by accident, as the Admin UI does not show these as checkboxes.
adam commented 2025-12-29 20:21:45 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 7, 2023):

@kkthxbye-code's proposal above has been captured under #12207. Closing this out as no further action is required.

@jeremystretch commented on GitHub (Apr 7, 2023): @kkthxbye-code's proposal above has been captured under #12207. Closing this out as no further action is required.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: under review type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7320
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?