* Fixes #22538: Add security note for HTTP_CLIENT_IP_HEADERS client-IP trust * Clarify header naming and leftmost-address behavior in client IP warning
This commit is contained in:
parent
54eda421fb
commit
9f47700e23
|
|
@ -98,6 +98,9 @@ An ordered list of HTTP request headers inspected to determine the source IP add
|
|||
|
||||
The client IP is used for source-address restrictions on API tokens and for logging failed login attempts.
|
||||
|
||||
!!! warning "Client IP trust"
|
||||
The headers listed here are trusted as the source of the client IP address. Trusting `X-Forwarded-For` (`HTTP_X_FORWARDED_FOR`) or `X-Real-IP` (`HTTP_X_REAL_IP`) is safe only when NetBox is deployed behind a reverse proxy that overwrites these headers with the real client address. If NetBox is reachable directly, or the proxy appends to or passes through a client-supplied value (NetBox uses the leftmost address, which the client controls when the proxy appends), a client can spoof its apparent IP address and defeat API token client IP restrictions. Deployments without a trusted proxy should set `HTTP_CLIENT_IP_HEADERS = ('REMOTE_ADDR',)`.
|
||||
|
||||
---
|
||||
|
||||
## HTTP_PROXIES
|
||||
|
|
|
|||
|
|
@ -807,6 +807,8 @@ By default, a token can be used to perform all actions via the API that a user w
|
|||
|
||||
Each API token can optionally be restricted by client IP address. If one or more allowed IP prefixes/addresses is defined for a token, authentication will fail for any client connecting from an IP address outside the defined range(s). This enables restricting the use a token to a specific client. (By default, any client IP address is permitted.)
|
||||
|
||||
The client IP address is determined from the HTTP headers configured by [`HTTP_CLIENT_IP_HEADERS`](../configuration/system.md#http_client_ip_headers); see the security note there regarding header trust.
|
||||
|
||||
#### Creating Tokens for Other Users
|
||||
|
||||
It is possible to provision authentication tokens for other users via the REST API. To do, so the requesting user must have the `users.grant_token` permission assigned. While all users have inherent permission by default to create their own tokens, this permission is required to enable the creation of tokens for other users.
|
||||
|
|
|
|||
Loading…
Reference in New Issue