Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
False
-
None
-
False
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Workaround Exists
-
Description
JWT Claim Check policy bypass the JWT check and continues to the backend API if the request URI contain special character such as space. For example " /foo/ bar"
Mapping Rule:
GET /groups/{groupID}/deduction$
Policy configuration
{ "combine_op": "and", "methods": [ "GET" ], "operations": [ { "op": "matches", "jwt_claim_type": "liquid", "jwt_claim": "{{ roles | join: '|'}", "value_type": "plain", "value": "groups:resource:read" } ], "resource": "/groups/{groupID}/deductions$" }
When request is sent with invalid JWT role i.e. "policy:resource:crud"
- GET "/groups/123/deductions$" => return 403 as expected
- GET "/groups/ 123/deductions$" => expected 403 but the request reach backend service and return 200
- GET "/groups/%20123/deductions$" => also return 200, expected 403
Examining the code, the observed behavior can be explained as follows
- Request URI is captured un-escaped
- The policy performs mapping rule matching before checking the jwt token
Due to (1) the request uri will be captured as "/groups/ 123/deductions" , this will NOT match "/groups/{groupID}/deductions$" => return false without checking the JWT token
However, if the uri is escaped "/groups/ 123/deductions" become "/groups/%20123/deductions" => this will then match the "/groups/{groupID}/deductions$" and JWT check will be performed => return 403
The problem also occurs if white space appears in another location, i.e. /foo%20bar/ or /foo%20/bar . Customers also reported that there could be other special characters that could cause this issue. For example: /groups/%0Afoo/deductions
Attachments
Issue Links
- links to
-
RHEA-2024:129854 Release of apicast-operator 0.12.1mas for RHOAM - Containers
- mentioned on