GHSA-vvjr-4qwm-6xjx: 
Python vulnerability analysis and mitigation

Summary

HARP forwards the request path to the endpoint's upstream URL. When the endpoint URL has a path (for example http://upstream/api/v1/), clients are meant to reach only that subtree. Requests carrying encoded dot segments can leave it: HARP forwards them unchanged, and an upstream that decodes and then normalises the path resolves them above the base path, to other paths on the same origin (for example http://upstream/admin).

Impact

Affects any HARP endpoint whose remote URL has a path prefix, when the upstream (or something between HARP and it) decodes percent-encoding and then resolves dot segments. Examples: nginx (routing or static files), Java servlet containers such as Tomcat or Spring (..;), IIS (\), or two decoders in a row (%252e). An unauthenticated client of the proxy port can then send requests to upstream paths the operator did not expose through that endpoint. The request stays on the configured upstream origin. Upstreams that route on the decoded path without resolving dot segments (for example aiohttp, Starlette) are not affected.

• Versions before 0.10.0 apply no containment check: %2e%2e/, ..%2f, .%2e and similar are forwarded unchanged.
• 0.10.0 to 0.11.0 refuse single-encoded dot segments but still forward double-encoded ones (%252e%252e/, ..%252f) and ;-parameter ones (..;/, %2e%2e;/), as well as overlong UTF-8 and fullwidth dots.

Patches

Fixed in 0.11.1 and 0.12.0. HARP now refuses with 400 Bad Request any request path that holds a . or .. segment under any decoding an upstream may apply: repeated percent-decoding, / \ and their encodings as separators, ; parameters, NUL truncation, overlong UTF-8 and Unicode normalisation.

Workarounds

• Normalise or reject at the edge: put a reverse proxy in front of HARP that refuses request targets containing %2e, %252e, %2f, %5c, \ or ; in the path.
• Enforce access control on the upstream itself instead of relying on the endpoint's base path.
• Point each endpoint at an upstream origin that exposes only the intended subtree.

Details

HARP reads the request path from the ASGI raw_path, which is percent-encoded as received. Before 0.10.0 it joined that path to the endpoint URL with urljoin, which does not decode, so encoded dot segments reached the upstream unchanged. 0.10.0 added a guard on the raw path that recognises ., %2e and the separators /, \, %2f, %5c, but it decodes only one level and does not strip ; parameters.

PoC

Upstream: anything on 127.0.0.1:8000 that decodes and then resolves dot segments (for example nginx). harp-proxy server --endpoint api=4000:http://127.0.0.1:8000/api/v1/ curl --path-as-is 'http://127.0.0.1:4000/%2e%2e/%2e%2e/admin' # < 0.10.0 curl --path-as-is 'http://127.0.0.1:4000/%252e%252e/%252e%252e/admin' # 0.10.0 to 0.11.0, double-decoding upstream curl --path-as-is 'http://127.0.0.1:4000/..;/..;/admin' # 0.10.0 to 0.11.0, Tomcat/Spring upstream The upstream receives /api/v1/%2e%2e/%2e%2e/admin (or the variant) and serves /admin. Patched versions answer 400 and send nothing upstream.

Credits

Reported by @kta1kri.