CGI clients may be able to control `current-proxy-servers`
Nobody has claimed this yet.
- Dominant language
- Racket
- Stars
- 5.2k
- Forks
- 698
- Avg merge
- 18h 34m
- Merged PRs (30d)
- 5
Description
The initial value of the current-proxy-servers parameter is initialized based on several environment variables. One rule says that:
plt_http_proxy,PLT_HTTP_PROXY,http_proxy,HTTP_PROXY,all_proxy, andALL_PROXY, configure the HTTP proxy, where the former takes precedence over the latter.
(Apparently programs like CERN libwww, wget, and curl made different capitalization choices initially, so now everyone has to check both.)
Unfortunately, the uppercase HTTP_PROXY is also used for a different purpose: CGI servers use environment variables to communicate HTTP headers to scripts, and a Proxy: header (which is not a standard) would be passed as HTTP_PROXY. If your CGI script performs HTTP requests, a client could use this collision to make your requests use a proxy of their choice.
(I haven't seen anything explicitly discussing the related HTTPS_PROXY variable. IIRC, CGI uses HTTP_ variables for both HTTP and HTTPS requests, so it wouldn't be an issue—but it would be good to confirm that!)
There's some background here: https://access.redhat.com/security/vulnerabilities/httpoxy
The approach adopted by Python in https://github.com/python/cpython/commit/17742f2d45c9dd7ca777e33601a26e80576fdbf6 seems like a good model: they check for the REQUEST_METHOD environment variable, which indicates a CGI environment, and, if it is set, ignore the uppercase HTTP_PROXY while continuing to respect http_proxy. (Python apparently also checks HTTP_proxy, but we don't look for that and I don't think we should start.) An extra complication is that, per the Racket docs:
Since Windows environment variables are case-insensitive, [an] environment variable set’s key byte strings on Windows are case-folded. More precisely, key byte strings are coerced to a UTF-8 encoding of characters that are converted to lowercase via
string-locale-downcase.
So, on Windows, you have to ignore all variants of http_proxy if REQUEST_METHOD is set.
(I do still have one CGI script in Racket out there, though it doesn't make HTTP requests.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the initialization of current-proxy-servers described in net/url and trace how environment variables are read; confirm how REQUEST_METHOD and Windows case folding affect the available names. Done means CGI requests do not honor uppercase HTTP_PROXY or its Windows-folded variants, while non-CGI use and lowercase http_proxy behavior remain as intended, with coverage for both cases.
Written by the indexing model from the issue text.
Assessment
- Domain
- networking, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100