When extra request headers are specified by --header (or -H) options, and the request is to be sent through a proxy, curl sends the same set of extra headers to both the proxy and the origin (destination) server. This is often highly undesirable and may constitute a security issue. An example would be a rather typical situation of handling a https request through a proxy: client issues a plaintext CONNECT request to a proxy, and then opens a secure connection to the origin server through the tunnel provided by the proxy. If client includes user credentials or other authentication information in headers meant for the origin server, these headers will be also sent to the proxy in the CONNECT request. This causes two security issues: 1) sensitive information is leaked to the unintended party (proxy), and 2) it is transmitted in clear text.
I have noticed this problem while testing an authentication scheme that uses non-standard headers, but I believe the problem may also affect HTTP basic authentication (though only when handled with --header, rather than --basic). I did not test this issue on plaintext requests (those that get proxied by GET method).
To fix this problem, I propose to introduce --proxy-header option, that would specify headers for the proxy. In absence of this option, standard headers will be sent to the proxy, rather than those specified by --header. A change in libcurl will be required to handle two sets of headers properly. I have implemented such a change by modifying file lib/http.c, functions Curl_checkheaders and Curl_add_custom_headers, to use SessionHandle->mstate to determine the phase of the request, and then select between two sets of headers. However, my knowledge of curl code internals proved too limited to develop anything more than a quick and dirty hack, and for this reason I do not include a patch.
I will gladly perform additional tests if needed.
curl -V
curl 7.34.0 (x86_64-unknown-linux-gnu) libcurl/7.34.0 OpenSSL/0.9.8k zlib/1.2.3.4
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: Largefile NTLM NTLM_WB SSL libz
uname -a
Linux tiny 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
This was brought up in http://curl.haxx.se/mail/lib-2012-04/0284.html as well, but didn't go very far. But, if you post patches to the curl-library mailing list, you'll likely receive some helpful suggestions on how to improve them! Patches make it much more likely this problem will be solved any time soon.
There was a recent update of that patch set posted by Vijay Panghal on Jan 9th this year (see link below), which I believe we can work on to get merged after the pending release. I've been wanting to, and with some additional attention and help I'm sure we can manage!
http://curl.haxx.se/mail/lib-2014-01/0079.html
I don't think that modifications I made are ready to be posted anywhere. Unfortunately, I was working on a project that was seriously behind schedule and I did not have time to fix this problem properly, the result being a rather ugly hack. It is also untested apart from a particular use case. I think it will be better to start fresh. I browsed through Vijay's patch and I find it promising. I will try to find some time to test it. What would be the best place to post results: here, on the mailing list, or somewhere else?
Last edit: Maciej Puzio 2014-01-22
I think it will be best to take it on the mailing list like other patches for a wider audience and more input and review.
One of the trickier parts this change involves is to make sure we preserve backwards compatible behavior for existing applications while introducing this new ability to new ones.
Testing done, results and my comments posted to the mailing list. I will include here a link to the message once it gets approved by the moderator.
Edit: The link is http://curl.haxx.se/mail/lib-2014-01/0200.html
Last edit: Maciej Puzio 2014-01-24
This feature is now in git!