Get Token call to API, returns 403 rather than 404 if token not found

[snesbittsea]

Overview of the Issue

If a call is made to get a token that does not exist, the Consul API returns a 403 (Forbidden) error rather than a 404 (Not found error)

Reproduction Steps

Steps to reproduce this issue, eg:

1. curl -vv --header "X-Consul-Token: xxx" -X GET http://dev-appserver01.lxd:8500/v1/acl/token/non-existent_token_accessor id
2. Result is:

• Trying 10.48.66.116:8500...
• TCP_NODELAY set
• Connected to dev-appserver01.lxd (10.48.66.116) port 8500 (#0)

GET /v1/acl/token/dfe93c72-ace9-1472-601b-ae6089f8648e HTTP/1.1
Host: dev-appserver01.lxd:8500
User-Agent: curl/7.68.0
Accept: /
X-Consul-Token: a3d684c1-b6cf-48ec-bd26-6da45afb6006

• Mark bundle as not supporting multiuse
  < HTTP/1.1 403 Forbidden
  < Vary: Accept-Encoding
  < X-Consul-Index: 208163
  < X-Consul-Knownleader: true
  < X-Consul-Lastcontact: 0
  < Date: Sat, 01 Aug 2020 18:30:34 GMT
  < Content-Length: 13
  < Content-Type: text/plain; charset=utf-8
  <
• Connection #0 to host dev-appserver01.lxd left intact
  ACL not found%

Consul info for both Client and Server

agent:
check_monitors = 0
check_ttls = 0
checks = 0
services = 0
build:
prerelease =
revision = 3111cb8
version = 1.8.0
consul:
acl = enabled
bootstrap = true
known_datacenters = 1
leader = true
leader_addr = 10.48.66.116:8300
server = true
raft:
applied_index = 250024
commit_index = 250024
fsm_pending = 0
last_contact = 0
last_log_index = 250024
last_log_term = 5
last_snapshot_index = 245794
last_snapshot_term = 5
latest_configuration = [{Suffrage:Voter ID:5c23389c-b64e-3396-2343-41bb2f0adc30 Address:10.48.66.116:8300}]
latest_configuration_index = 0
num_peers = 0
protocol_version = 3
protocol_version_max = 3
protocol_version_min = 0
snapshot_version_max = 1
snapshot_version_min = 0
state = Leader
term = 5
runtime:
arch = amd64
cpu_count = 4
goroutines = 105
max_procs = 4
os = linux
version = go1.14.4
serf_lan:
coordinate_resets = 0
encrypted = false
event_queue = 0
event_time = 5
failed = 0
health_score = 0
intent_queue = 0
left = 0
member_time = 5
members = 3
query_queue = 0
query_time = 1
serf_wan:
coordinate_resets = 0
encrypted = false
event_queue = 0
event_time = 1
failed = 0
health_score = 0
intent_queue = 0
left = 0
member_time = 1
members = 1
query_queue = 0
query_time = 1

Operating system and Environment details

Consul running in Docker container hosted by a LXD container.

[mikemorris]

I believe this is the intended functionality to avoid leaking information about the existence of a token.

[snesbittsea]

If the point is to prevent leaking token existence, I'm not sure anything is accomplished when the return message is "ACL not found". Nor does a 403 make sense when the query has authorization to read/list tokens. And of course I can easily work around it by generating a list and doing the query in my own code against the returned list.

Strikes me as current behavior is security through obscurity and thereby provides merely the illusion of security.

It also seems to me to be a security issue since the absence of a token is being leaked by the message "ACL not found"

Or am I missing something obvious (not unusual :-)

[blake]

We revisited this issue and agree that the current behavior is incorrect. The API should be returning a 404 when a request to lookup a nonexistent token is issued with a token that has acl:read privileges.

The acl.ErrNotFound error being returned in hashicorp/consul/agent/acl_endpoint.go#L164 should instead be a NotFoundError with an accompanying error message (e.g., NotFoundError{Reason: "No such token"}). The API will then correctly return a 404 status code along with the error message.

[gunadhya]

Hi @blake , I'd like to work on this.

[blake]

@gunadhya You're welcome to fix this. Feel free to submit a PR and we'll review. 🙂

[mas15]

Hi @dnephin I'd like to work on this :)

[sriramr98]

Hi @blake.
I think this has still not been picked up since 2021. I would love to pick this up and send a PR

[sriramr98]

Hi @blake . I just checked the code and it seems like this isn't an issue anymore as the API's have bee fixed. In that case, can we close the issue so that it makes the issue board a little bit cleaner?

[david-yu]

@sriramr98 Thanks for notifying will close! If folks have further issues please open a new issue as this issue is over three years old.