Description
Description
Unauthorised fetching of an entity is masked as a 404 NOT FOUND error status instead of 401 UNAUTHORIZED, to avoid leaking the existence or not of said entity.
However, the response body is different in shape from a genuine 404, allowing for determining that an entity exists from an unprivilieged stand point.
Impacted endpoints:
👉 May discover valid tokens via unauthenticated request
Practicality: very low: when probing blind, need to figure out long, non sequential alpha-numerical strings to test (assuming their generation is random and crypto-safe); if obtaining a leak, the probing is not useful
👉 May discover valid tokens as an authenticated, non-admin user
Practicality: very low, for the same reason
👉 May discover injects and related existing simulation or scenario as an authenticated, non-admin user
Practicality: very low: inject IDs are non sequential UUIDv4 so the address space is unpractically large
the value of knowing a specific inject exists via its ID
Risk: injects may contain sensitive data, and knowing valid IDs in advance may help further probing or attacks leading to a possible, eventual leak
Recommendation
The error message given with a 404 response status should always be of the same shape, and not provide a vector for probing.
Details
401 to 404 switch handler code: static "NOT_FOUND" string for body
openbas/openbas-api/src/main/java/io/openbas/rest/helper/RestBehavior.java
Lines 108 to 117 in b385212
Genuine 404 handler code: get a message constructed from the actual exception
openbas/openbas-api/src/main/java/io/openbas/rest/helper/RestBehavior.java
Lines 135 to 140 in b385212