[
https://issues.apache.org/jira/browse/HTTPCLIENT-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781470#comment-16781470
]
Oleg Kalnichevski commented on HTTPCLIENT-1973:
-----------------------------------------------
[~asmotrakov] This is precisely the reason HttpClient provides cookie policy
APIs as well as authentication APIs so that cookies can be included in requests
based on their scope and the security context and credentials disclosed only
when properly challenged. If one just dumbly sticks headers into a request
HttpClient has not choice but to assume they know what they are doing.
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]
