[
https://issues.apache.org/jira/browse/HTTPCLIENT-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780696#comment-16780696
]
Oleg Kalnichevski commented on HTTPCLIENT-1973:
-----------------------------------------------
[~asmotrakov] Why would one want to remove {{Proxy-Authorization}} header is
completely beyond me. This header has nothing to do with the target server and
its inclusion in the redirect request is perfectly reasonable. Same story goes
for {{Cookie}} header. There are cookies that apply to multiple hosts in the
same domain. One may need to include such cookies in the redirect request in
order to get it accepted by the target server the request is redirected to.
Oleg
> HttpClient may leak sensitive headers while handling redirects
> --------------------------------------------------------------
>
> Key: HTTPCLIENT-1973
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1973
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Reporter: Artem Smotrakov
> Priority: Major
> Attachments: RedirectExec.java.patch, test_and_patch.tar.gz
>
>
> (this bug was created after discussing it on [email protected])
> I don't think it's a big problem but maybe HttpClient should be updated.
> Let's consider the following environment:
> - [http://trusted.server|http://trusted.server/] asks a user to authenticate
> via one of the HTTP authentication schemes
> -
> [http://trusted.server/redirect?to=<url|http://trusted.server/redirect?to=%3Curl]>
> is an open redirect which returns 301 code, and redirects a client to the
> specified URL
> - [http://attacker.server|http://attacker.server/] is a third-party server
> which is controlled by an attacker
> If I understand correctly, currently following redirects is enabled by
> default. If HttpClient is configured with sensitive headers (like
> Authorization, Proxy-Authorization, Cookie), then HttpClient may leak these
> sensitive HTTP headers to third parties when it follows redirects.
> Please find a test for this in attachment. I tested it with HttpClient 4.5.7
> I noticed that if an application sets cookies and authentication data via
> standard HttpClient API, then the sensitive headers are not sent while
> handling redirects (please see in the test). But if the application
> explicitly sets sensitive headers, then they are sent. I am not sure if it
> was implemented like that intentionally.
> I don't think it's a severe issue, and it requires several pre-conditions
> such as:
> - an attacker has to be able to pass a URL to the client
> - there should be an open redirect (which is often considered insecure)
> - the client has to set sensitive headers via addHeader() method
> Also there are some ways how applications can mitigate the problem but it
> would require updating the application code:
> - [Application code can disable redirect
> handling|http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#disableRedirectHandling]
> - [Application code can set its own redirect strategy where it can decide
> which redirects to
> follow|http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#setRedirectStrategy(org.apache.http.client.RedirectStrategy)]
> Nevertheless, I am wondering it HttpClient could catch this situation and
> prevent leaking sensitive headers.
> Similar issues have been fixed in several HTTP clients such as curl and
> HttpURLConnection.
> I am also attaching a patch which fixes the issue. The patch updates
> RedirectExec class to filter out sensitive headers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
