HTTP content-length a security risk?

R

Roedy Green

Here is a little correspondence I had with my ISP

A recent security/compatibility update to Apache2 is the reason for
this behaviour. The serious problems occur when "Transfer-Encoding:
chunked" is sent by Apache2 in the HTTP headers -- this specific
header, which improves performance, is not compatible with, and also
causes a security problem (I'm not sure why, and I remain skeptical of
this particular claim, but I'm comfortable with the compatibility
justification), can't be sent as well, so Apache2 omits it.


Anyone know anything about this? Why would using content-length
present a security risk?
 
T

Thomas Hawtin

Roedy said:
Anyone know anything about this? Why would using content-length
present a security risk?

I don't know about this case, but there was a case were Java applets
could persuade a proxy that the HTTP (1.1 or 1.0 with extras) request
had finished when the JRE didn't think it had. The applet could then
send data which the proxy took as another request. I assume the applet
could do that by sliding in a content-length header, or something similar.

You might think this is known, has been fixed and therefore isn't a
problem. However, security bugs seem to have a habit of reoccurring.
Last year Sun took three attempts to fix much the same critical Java bug
that appeared seven times (although apparently requiring differing
levels of ingenuity to exploit).

Tom Hawtin
 
C

Chris Uppal

Roedy said:
Anyone know anything about this? Why would using content-length
present a security risk?

HTTP request splitting, one tool for request smuggling, cache
poisoning, and other fun and games.

Good paper (which seems to require registration these days) here:
http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf

Short summary (no registration) here:
http://www.securiteam.com/securityreviews/5GP0220G0U.html

Just one more proof that a little complexity is a dangerous thing.

Here's the "Executive Summary" from the paper:

==========
HTTP Request Smuggling works by taking advantage of the discrepancies
in parsing when one or more HTTP devices/entities (e.g. cache server,
proxy server, web application firewall, etc.) are in the data flow
between the user and the web server. HTTP Request Smuggling enables
various attacks – web cache poisoning, session hijacking, cross-site
scripting and most importantly, the ability to bypass web application
firewall protection. It sends multiple specially crafted HTTP requests
that cause the two attacked entities to see two different sets of
requests, allowing the hacker to smuggle a request to one device
without the other
device being aware of it. In the web cache poisoning attack, this
smuggled request will trick the cache server into unintentionally
associating a URL to another URL’s page (content), and caching this
content for the URL. In the web application firewall attack, the
smuggled request can be a worm (like Nimda or Code Red) or buffer
overflow attack targeting the web server. Finally, because HTTP Request
Smuggling enables the attacker to insert or sneak a request into the
flow, it allows the attacker to manipulate the web server’s
request/response sequencing which can allow for credential hijacking
and other malicious outcomes.
==========

-- chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,754
Messages
2,569,521
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top