You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Artem Smotrakov (JIRA)" <ji...@apache.org> on 2019/02/28 14:54:00 UTC
[jira] [Commented] (HTTPCLIENT-1973) HttpClient may leak sensitive
headers while handling redirects
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16780597#comment-16780597 ]
Artem Smotrakov commented on HTTPCLIENT-1973:
---------------------------------------------
Let me know in case you decide to fix it, and I can create a pull request.
> 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 security@apache.org)
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org