Requesting re-assessment of closure of bug 8428 - Get Token call to API, returns 403 rather than 404 if token not found

Generally don’t like to question closing a bug, but the reason given for closure doesn’t make sense to me and - if accurate - suggests a security issue.

The core issue here is that under Consul 1.8 an authorized query for a non-existent token yields a 403 (permission denied error) rather than a 404 (not found). Reason given for closing was this behavior was as designed in order to prevent an indirect means of finding out about tokens.

This doesn’t make sense to me given 1) the query was made using a token with master level privileges and 2) the returned error message is “ACL not found” (which certainly doesn’t obscure the fact that the token doesn’t exist).

So it seems to me that there is either a problem in that the API is returning a misleading error code which will require unnecessary and fragile work arounds (catch error, parse message, hope to god the error message never changes) or a security issue since the absence of the token is leaking.

Thx,

-steve

Hi @snesbittsea,

I see your point here and I agree we should re-evaluate this behavior.

I will start an internal discussion on this, and provide an update both here and on the GitHub issue after our team has had a chance to review.

1 Like

Hi Steve,

We discussed this and agree that the current behavior is incorrect. The API should return a 404 when the request 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 something like NotFoundError{Reason: "No such token"}. The API will then correctly return a 404 status code along with this error message.

I’ll re-open the issue on GitHub and mark this as a bug. Thanks for reporting it!

1 Like