GHSA-49wc-vv82-h8j7: 
Python 脆弱性の分析と軽減

Summary

HARP proxies a request to the upstream URL configured for the endpoint it hits. A client of the proxy port can override that upstream: a request whose path carries an absolute URL (for example GET /http://169.254.169.254/latest/meta-data/ HTTP/1.1) makes HARP drop the configured host and send the request to the host named in the path instead. HARP returns the upstream response to the client, so it acts as an open proxy and a server-side request forgery (SSRF) primitive.

Impact

Any HARP deployment on an affected version is exposed: every configured endpoint forwards to whatever origin the client writes into the request path. An unauthenticated client that can reach a proxy listen port can make HARP issue requests to arbitrary hosts and read the responses. This includes hosts the client cannot reach directly: cloud instance metadata (169.254.169.254), internal APIs and admin panels, and other services inside the deployment's network. No egress allow-list exists in the default configuration, and the proxy port carries no client authentication, so the only precondition is network reach to the port.

Patches

Fixed in 0.10.0. The forwarded URL is now built from the path component alone, pinned to the endpoint's configured origin, so a host named in the request path can no longer change it. Upgrade to 0.12.0 (or 0.11.1) to also pick up the later dot-segment containment hardening.

Workarounds

• Put a reverse proxy in front of HARP that rejects any request target that is not origin-form, i.e. one that contains a scheme (http:, https:) or an authority in the path.
• Restrict network access to the proxy listen ports to trusted clients only.
• Firewall HARP's own egress so it cannot reach internal or metadata endpoints. Upgrading is the only complete fix.

Details

Root cause is in harp_apps/proxy/controllers.py, AbstractHttpProxyController._get_next_url_for. Through 0.9.1 it computed: relative_url = context.request.path.lstrip("/") return base_url, urljoin(base_url, relative_url) + ... context.request.path is attacker-controlled. When it carries a scheme and host (http://evil/...), urljoin(base_url, "http://evil/...") discards base_url's host and returns the attacker's URL; the lstrip("/") blocked the protocol-relative //host form but not the absolute scheme://host form. The result is forwarded with no check that it stays on the configured upstream origin. 0.10.0 takes only the path component of the incoming request, refuses control characters and dot segments, and reconstructs the forwarded URL from the endpoint's own scheme and host, so the origin is fixed by construction and a host in the request path has no effect.

PoC

Point an endpoint at a harmless upstream A and run a second server B as the "internal" target: harp-proxy server --endpoint api=4860:http://127.0.0.1:4861/ Then, against a vulnerable version: curl --path-as-is 'http://127.0.0.1:4860/http://127.0.0.1:4862/pwned' HARP forwards the request to 127.0.0.1:4862 (B) instead of the configured 127.0.0.1:4861 (A) and returns B's response. On 0.10.0 and later the request stays on A (B is never contacted).