Repository navigation
fix(proxy): refuse dot segments resolved after the route check - #1163
Conversation
Signed-off-by: Oleksandr Piskun <oleksandr2088@icloud.com>
3c3dcdf to
a3e3d7f
Compare
Walkthrough
Priority: Merge Risk:
|
There was a problem hiding this comment.
Actionable comments posted: 1

Review info
-
Run configuration-
- Source mode: Auto
- Repository: Unavailable
- Branch: Unavailable
- File: No configuration file from this repository applied
- Commit: Unavailable
- Layers: Organization UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
3b34fe0a-1dd0-4cdb-a0ae-4ae38384e295
Files selected for processing: 3-
CHANGELOG.mdlib/Controller/ExAppProxyController.phptests/php/Controller/ExAppProxyControllerTest.php
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.
-
The ExApp proxy refuses a path with a
..segment before it looks for a matching route, so that the route is decided on the path the ExApp serves. The check only knew..followed by/,%2For the end of the path, and three other forms reached the ExApp as a different path than the one the route was matched against:..;and..;x=1: Tomcat and other Java servers drop;path parameters and then resolve.....followed by%3For%23: the proxy forwards the path cut at the decoded?or#, and curl resolves the..that is now at the end, soa/..%3F/breaches the ExApp as/..segments, also percent-encoded: curl removes them before it sends the request, so./admin/xis matched as/./admin/xwhile the ExApp receives/admin/x.The proxy now answers 404 for
.and..segments, also percent-encoded, followed by/,;,%3F,%23,%2For the end of the path. Browsers resolve dot segments before they send a request, so ExApp pages and their API calls do not contain them; names such asa..b,..foo,.well-knownorfile;v=1are forwarded as before.Changes
.segments and segments followed by;,%3For%23.