[
https://issues.apache.org/jira/browse/HTTPCLIENT-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780716#comment-16780716
]
Artem Smotrakov commented on HTTPCLIENT-1973:
---------------------------------------------
[~olegk] Right, cookies may apply to multiple hosts in domain "trusted.server",
so that one may want them to be sent to hosts under domain "trusted.server"
while handling a redirect. On the other hand, if I understand correctly, such
cookies should not be sent to hosts which don't belong to "trusted.server". I
think if such headers are set via addHeader() method, there is no way to
distinguish these two cases, so that HttpClient can only send all headers or
filter out sensitive ones in all cases. In general, I think addHeader() method
should not be used to set such headers at all but it still may be used. If it's
decided not to change the current behavior, it might make sense to mention the
current behavior in the docs.
> 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]
