Slashdot Mirror
HTTP Request Smuggling
cyphersteve writes "Multiple vendors are vulnerable to a new class of attack named 'HTTP Request Smuggling' that revolves around piggybacking a HTTP request inside of another HTTP request, which could let a remote malicious user conduct cache poisoning, cross-site scripting, session hijacking, as well as bypassing web application firewall protection and other attacks. HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more HTTP devices are between the user and the web server. CERT has ranked this attack and the associated vulnerabilties found in multiple products as High Risk. The authors (Amit Klein, Steve Orrin, Ronen Heled, and Chaim Linhart) have published a whitepaper describing this technique in detail."
AC = No Karma Whoring
HTTP REQUEST SMUGGLING
CHAIM LINHART (chaiml@post.tau.ac.il)
AMIT KLEIN (aksecurity@hotpop.com)
RONEN HELED
AND STEVE ORRIN (sorrin@ix.netcom.com)
A whitepaper from Watchfire
TABLE OF CONTENTS
Abstract 1
Executive Summary 1
What is HTTP Request Smuggling? 2
What damage can HRS inflict? 2
Example #1: Web Cache Poisoning 4
Example #2: Firewall/IPS/IDS evasion 5
Example #3: Forward vs. backward HRS 7
Example #4: Request Hijacking 9
Example #5: Request Credential Hijacking 10
HRS techniques 10
Protecting your site against HRS 19
Squid 19
Check Point FW-1 19
Final note regarding solutions 19
About Watchfire 20
References 21
Copyright © 2005 Watchfire Corporation. All Rights Reserved. Watchfire, WebCPO, WebXM,
WebQA, Watchfire Enterprise Solution, WebXACT, Linkbot, Macrobot, Metabot, Bobby,
Sanctum, AppScan, the Sanctum Logo, the Bobby Logo and the Flame Logo are trademarks or
registered trademarks of Watchfire Corporation. GómezPro is a trademark of Gómez, Inc., used
under license. All other products, company names, and logos are trademarks or registered
trademarks of their respective owners.
Except as expressly agreed by Watchfire in writing, Watchfire makes no representation about the
suitability and/or accuracy of the information published in this whitepaper. In no event shall
Watchfire be liable for any direct, indirect, incidental, special or consequential damages, or
damages for loss of profits, revenue, data or use, incurred by you or any third party, arising from
your access to, or use of, the information published in this whitepaper, for a particular purpose.
www.watchfire.com
HTTP REQUEST SMUGGLING
© Copyright 2005. Watchfire Corporation. All Rights Reserved. 1
ABSTRACT
This document summarizes our work on HTTP Request Smuggling, a new attack technique that has
recently emerged. We'll describe this technique and explain when it can work and the damage it can do.
This paper assumes the reader is familiar with the basics of HTTP. If not, the reader is referred to the
HTTP/1.1 RFC [4].
EXECUTIVE SUMMARY
We describe a new web entity attack technique - "HTTP Request Smuggling." This attack technique, and
the derived attacks, are relevant to most web environments and are the result of an HTTP server or device's
failure to properly handle malformed inbound HTTP requests.
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.
HTTP REQUEST SMUGGLING
© Copyright 2005. Watchfire Corporation. All Rights Reserved. 2
WHAT IS HTTP REQUEST SMUGGLING?
HTTP Request Smuggling ("HRS") is a new hacking technique that targets HTTP devices. Indeed, whenever
HTTP requests originating from a client pass through
Why not just (a) be less trusting of Content-Length, and (b) reject malformed requests with two of them?
One line blog. I hear that they're called Twitters now.
Here is a link:p df
http://www.gatech-edu.org/HTTP-Request-Smuggling.
Due to bad handling of borderline html, some web servers will see extra requests that front end servers (cache, proxies) don't see. This is due http keepalive (so that more than one request can be processed in a stream) and malicious http headers. This seems to be implemented mostly by sending duplicate or invalid content length headers.
I'm sure that all of these problems will be quickly patched. All of these issues would be fixed by tighter HTTP parsing specifications. However, buggy software will always exist, and always be exploited.
Why not just (a) be less trusting of Content-Length, and (b) reject malformed requests with two of them?
Apache already does this. Multiple content-length fire an error, as well as
requests using chunked transfer-encoding.
You're forced to trust Content-Length because it's the only way to know when
to stop reading. It's just as if you proposed to be less trusting on the length
field in an IP packet.
Willy
NetApp's NetCache.
There are already some simple proposals that go a long way to solving the man in the middle issue already, without resorting to grossly inefficient schemes such as yours (or HTTPS). The problem is in getting them adopted.