-
Bug
-
Resolution: Done
-
Major
-
None
-
False
-
-
False
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Workaround Exists
-
-
-
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
- links to
-
RHEA-2024:129854
Release of apicast-operator 0.12.1mas for RHOAM - Containers
- mentioned on