A route parameter constraint can be bypassed with doubly percent-encoded input, so a handler receives characters that the router was configured to reject.
Impact
A route parameter constraint can be bypassed with doubly percent-encoded input, so a handler receives characters that the router was configured to reject.
Slim (4.0.0-4.15.2) decodes the request path before matching a route, then decodes each captured argument a second time before passing it to the handler. This means that validation will run against a different value than the one the application receives.
Given the route /test/{value:[^/]+}, which forbids a path separator:
| Stage |
Value |
| Incoming request |
/test/a%252Fb |
| Path decoded, before matching |
a%2Fb |
Checked against [^/]+ |
passes, no separator present |
| Argument decoded again, at the handler |
a/b |
Singly-encoded input is not affected. /test/a%2Fb is a 404, since the decode happens before matching and the resulting separator breaks the capture. Only doubly-encoded input reaches a handler in a different form than the router validated.
You are affected if you run Slim 4.0.0 through 4.15.2 and use route placeholder values without revalidating them.
For example consider a file download controller that maps the value to the filesystem:
$app->get('/download/{file:[^/]+}', function ($request, $response, array $args) {
// The route restricts $file to a single path segment.
$path = __DIR__ . '/files/' . $args['file'];
$response->getBody()->write(file_get_contents($path));
return $response;
});
On affected versions, /download/subdir%252Fsecret.txt would reach the handler as files/subdir/secret.txt, including the subdirectory that was restricted in the route pattern.
Note that this would also defeat filtering applied ahead of the application. A proxy or WAF that decodes once sees the inert %2e%2e%2f while the handler receives ../.
Slim 3.x is not affected.
Patches
Fixed in version 4.15.3. Upgrade with:
composer require slim/slim:^4.15.3
RoutingResults::getRouteArguments() no longer decodes captured values. It never needed to as the path they were captured from already decoded them.
This means that the $urlDecode parameter of getRouteArguments() is now ignored.
Workarounds
If you cannot upgrade, revalidate route placeholder values in the handler and do not rely on the route pattern. Reject any argument containing a path separator before using it.
References
Credits
Thanks to NomanProdhan and Ilia Alshanetsky for independently reporting this issue.
A route parameter constraint can be bypassed with doubly percent-encoded input, so a handler receives characters that the router was configured to reject.
Impact
A route parameter constraint can be bypassed with doubly percent-encoded input, so a handler receives characters that the router was configured to reject.
Slim (4.0.0-4.15.2) decodes the request path before matching a route, then decodes each captured argument a second time before passing it to the handler. This means that validation will run against a different value than the one the application receives.
Given the route
/test/{value:[^/]+}, which forbids a path separator:/test/a%252Fba%2Fb[^/]+a/bSingly-encoded input is not affected.
/test/a%2Fbis a 404, since the decode happens before matching and the resulting separator breaks the capture. Only doubly-encoded input reaches a handler in a different form than the router validated.You are affected if you run Slim 4.0.0 through 4.15.2 and use route placeholder values without revalidating them.
For example consider a file download controller that maps the value to the filesystem:
On affected versions,
/download/subdir%252Fsecret.txtwould reach the handler asfiles/subdir/secret.txt, including the subdirectory that was restricted in the route pattern.Note that this would also defeat filtering applied ahead of the application. A proxy or WAF that decodes once sees the inert
%2e%2e%2fwhile the handler receives../.Slim 3.x is not affected.
Patches
Fixed in version 4.15.3. Upgrade with:
RoutingResults::getRouteArguments()no longer decodes captured values. It never needed to as the path they were captured from already decoded them.This means that the
$urlDecodeparameter ofgetRouteArguments()is now ignored.Workarounds
If you cannot upgrade, revalidate route placeholder values in the handler and do not rely on the route pattern. Reject any argument containing a path separator before using it.
References
Credits
Thanks to NomanProdhan and Ilia Alshanetsky for independently reporting this issue.