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."

Comments

Validation

[ilyanep]

Now let's take packet A. Do an MD5 sum (or similar) on it. Send it to the end user. Have the end user's browser do a similar check on it and send it to the server. IF the server green flags it, then show the page.

This shouldn't become a speed problem on broadband machines because it'll only mean 2 or 3 times more packets (but you can always increase packet size).

Call the new standard something like HTTPS 2.0.

Re:Validation

[Anonymous Coward]

It would mean not only 2 or 3 more packets but another full roundtrip, per transaction. It's also not feasible for the very reason why these attacks work: Intermediate HTTP devices modify the requests (proxies add Client-IP: headers, for example). That would invalidate the checksum.

Re:Validation

[mp3LM]

This shouldn't become a speed problem on broadband machines because it'll only mean 2 or 3 times more packets (but you can always increase packet size).

Are you serious?!?!? This could kill an already decently loaded web-server.
If it's twice as many packets, that's doubling the workload!

Also, I think you mis-read the issue. The issue isn't someone hijacking someone elses HTTP request, it's someone who wants to attack a server by sending a request inside there own request, in which case the checksum would still pass.

Re:Validation

[AndroidCat]

Why not just (a) be less trusting of Content-Length, and (b) reject malformed requests with two of them?

Re:Validation

[aNonMooseCowherd]

People who do this are supposed to set the evil bit (RFC 3514).

Re:Validation

[Jeff DeMaagd]

If it's twice as many packets, that's doubling the workload!

Now you have both typing and and conversational math. You will go far.

Re:Validation

[Anonymous Coward]

Unfortunately if they are able to succeed with this type of attack, an MD5 wouldn't really be a solution. http://it.slashdot.org/article.pl?sid=05/06/10/174 9256&tid=172&tid=93

Re:Validation

[Lord Kano]

Anyone capable of pulling off a man in the middle attack could intercept the MD5 sum. Send the user a false one, return a valid MD5 to the server and go on as usual.

LK

Re:Validation

[Bert690]

Getting the server to ack each page is going to be very costly, plus it doesn't actually solve the fundamental "man in the middle" vulnerability of HTTP, which is the basis of this and many other attacks on HTTP and its implementations.

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.

Re:Validation

[Master of Transhuman]

Nice.

I was about to cut and paste your "and and", then say "You will not." Unfortunately I cannot, so the rest of this post is not directed at you. Instead it is a rant about Firefox.

One of Firefox's NUMEROUS bugs just bit, and I can no longer cut and paste!

Somebody kindly fix Firefox's NUMEROUS MEMORY LEAKS!

Jesus, now I can NOT use the goddamn APOSTROPHE without it jumping to the FIND bar!

If this shit keeps up, it IS back to Opera!

Mozilla, STOP adding FEATURES until you FIX THE FUCKING BUGS!

and here's where...

[ohzero]

ISS steps in and claims that their products automagically figured this out, because they don't "use signatures" and that anyone who's a customer is automatically "protected." right.

Re:and here's where...

[Anonymous Coward]

Actually the whitepaper sates that IIS and Apache automatically dump the malformed packet.

Microsoft does write a few good lines of code.

Re:and here's where...

[ohzero]

flamebait? Anyone with half a clue would understand that this is just a fact. If you don't believe me.. watch the updates. I guarantee you that headlines will read almost verbatim what I said come Monday.

Then again, this is slashdot... I guess I shouldn't expect people to understand things.

Re:and here's where...

[ohzero]

ISS as in Proventia. Not IIS as in Pis sPoor Web Server.

Re:and here's where...

[gtwilliams]

Actually, according to TFA, Apache as a cache parses differently than Apache as a W/S thus allowing a form of the attack. And, according to TFA, IIS has a bug called the 48K bug where it arbitrarily cuts off certain requests (no Content-Type header) after 48K bytes.

Apache:

It should be noted that Apache's behavior is quite bizarre, since the request it creates by default lacks the Content-Length header, and thus will cause problems in most web servers (which assume Content-Length 0 in such case). That is, when a normal request with Transfer-Encoding: chunked is sent through Apache, it will arrive to the web server as a request with normal body, but without Content-Length, which will cause most web servers to ignore the body altogether.

IIS (5.0):

This makes it very easy to smuggle requests to IIS/5.0, because this behavior is non-standard and counter-RFC (and most likely, very little known).

Re:and here's where...

[drumist]

Microsoft does write a few good lines of code.

AC:

Don't worry, we fired the guy who did this on the spot. Thanks for bringing it to our attention.

Signed,
Bill

Re:Problem reading the PDF...

[Dogers]

Tried to do a copy and paste, but the lameness filter wont let me. DRM in force! ;)

This has been going on for some time.

[WindBourne]

I noticed that 3 months ago.

Article Text

[Anonymous Coward]

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

I AC posted the article

[camusflage]

I posted it.. It took deleting all the "..." crap in the ToC to get it past the lameness filter.

piggybacking

[Edzor]

I like to use 'piggybacking' as well, it makes me sound technical but cool at the same time.

Re:Problem reading the PDF...

[Damhna]

http://www.p45rant.net/boards/attachment.php?attac hmentid=8022

Why is this news?

[duh_lime]

If there is ANY communications path, it can be used for anything... If you have cooperating applications, anything that passes at least "a bit" can be subverted for another purpose. You could do Morse code using ICMP Echo Requests, with the packet size determining whether it's a dot or a dash... Whatever... Again, why is this particular technique news?

Re:Why is this news?

[cduffy]

Because some applications are cooperating although they're not supposed to.

Re:Why is this news?

[segmond]

Shut up! RTFP!

The attack allows attack worse than XSS if an XSS vulnerability exists since this time, it doesn't require you to intereact with the client. It allows cache poisoning. It allows you to smuggle data past some firewall/filters that try to prevent HTTP attacks by parsing requests, for example, so servers will filter out GET requests like /foo/../../../whatever or /foo?cmd.exe You can use this to bypass it. This is NEWS because it is a NEW attack. This is not about using HTTP as a tunnel for other form of communication.
This exploits the fact that the cache server/firewall and webserver might parse the same request different when it has two "Content Length:" in it... Read the paper.

Re:Why is this news?

[argent]

I have a better idea.

Use a webserver that's not subject to /foo/../../../ type attacks in the first place!

Re:Why is this news?

[Aeiri]

The attack allows attack worse than XSS if an XSS vulnerability exists since this time, it doesn't require you to intereact with the client.

It also requires the client to be behind X proxy which was attacked, or the server to be behind FW-1 with IIS. There are very restricted circumstances, and this should not be "highly critical", maybe moderate, but not highly critical. Highly critical should be reserved for a vulnerability which affects everyone, something that affects every program, every server, and every client. Much like US Homeland Security's "red" terror alert,

The way I see it is: IIS is reading the extra data as another request, that is a vulnerability. FW-1 is not truncating passed it's read (specified by the content-length it chose). Some proxy servers are vulnerable to cache poisoning (what's new, that's hard to completely fix sometimes).

This is just a bunch of vulnerabilities strung together being named under the same name, which is stupid. I think I'll make an exploit which exploits a buffer overflow in a firewall product then exploit a buffer overflow in Windows, however, I won't submit it as two separate vulnerabilities to Bugtraq and the vendors, I'll write a paper on it and call it my 2-Tier Magical Roundhouse Attack.

I think this appeared in DDJ sometime ago...

[soapdog]

Folks, hiding one HTTP request inside another is not the same HTTP request hijacking technique that appeared in Doctor Dobbs journal some months ago... I can't recall the edition...

Re:I think this appeared in DDJ sometime ago...

[cyphersteve]

that was HTTP Response Splitting (article: http://www.ddj.com/documents/s=9220/ddj0408g/0408g .html)
This is Request Smuggling, different method completely but some of the same outcomes are possible.

Question of Compatibility vs. Reliability

[l2718]

This exploit is interesting, and is related to a cultural issue: how do you handle malformed input?

There are two basic approached to this: either you reject it (the sound, security-concious way), or you attempt to make sense of it (the compatible way). The second solution allows your software to interface with badly-written external code, at the cost of interfacing with intentionally malformed requests like the exploit the describe.

The reason the exploit works is that different people have different methods for determining what the sender of the malformed packet really meant, and if two different interpretations are applied to the same packet you can use the resulting "confusion" to your advantage. Different recount results which depend on guessing "voter intent" from malformed ballots in Florida comes to mind.

Re:Question of Compatibility vs. Reliability

[iabervon]

The actual issue is cases where someone makes sense of malformed input and then passes that input on to something else. The proper thing to do is always pass on correctly-formed input. If you get malformed input and interpret it somehow, you then need to pass on your interpretation, not the original. The guideline is to be permissive in what you accept and strict in what you transmit; when you're passing something on, you need to canonicalize it in transit.

A good example of this is how the legal system works. When a court makes a decision on the application of a law to an unclear situation, that becomes part of the case law, such that there is a consistent interpretation, rather than an ambiguous situation being interpreted randomly each time it occurs.

Re:Question of Compatibility vs. Reliability

[MegaFur]

So, what you're saying is that this exploit is the Democrats' fault?

Ok, here's a good example: you're statement seems malformed to me--at least the content of your statement makes no sense and, is a near total non sequitor. Maybe it's meant to be mean, or maybe it's meant to be a joke. Whatever. What I would normally choose to do with such input is either ignore (reject) it, or ask for clarification.

In thise case (obviously) I've chosen to make an example of it instead.

Re:Question of Compatibility vs. Reliability

[Anonymous Coward]

But this isn't about merely malformed input. Two content-length headers is blatantly wrong input according to the RFC, and the server is required to reject it according to HTTP/1.1 I understand your point about culture, but don't think it applies here. People should just follow the standard (or RFC, in this case).

Re:Question of Compatibility vs. Reliability

[Anonymous Coward]

Wow, you sure use a lot of vertical space.

FYI, "<blockquote>" adds blank lines both before and after (unless it's the first thing in the post, in which case it doesn't add a blank line before), so you don't have to.
--
Anonymous sig

Re:Question of Compatibility vs. Reliability

[IggiFlynn]

...The proper thing to do is always pass on correctly-formed input...

That's what this attack exploits: two interpretations of what is 'correctly-formed input'. The cache/proxy looks at the request and says "yep looks good" and sends it on. It sees valid input. The workstation, on the other hand, takes the same request and sees something different, hence the exploit. It won't make a difference if the cache/proxy rewrites it or not, because it will simply repeat the attack to the workstation. If you mean that the proxy should translate the initial input into something it considers valid output then you run into slews of bugs trying to decide what the client was really trying to say (which could also be exploited).

Be very careful

[Anonymous Coward]

It is unethical and immoral. Some HTTP requests even time-out and have died doing this! Also be aware that some vigilante border gateway protocols have sprung up in the south looking for smuggled HTTP requests. Also new federal legislation may require all web servers to validate the HTTP request's green packets before responding.

Re:Be very careful

[PerspexAvenger]

*applause*

Ah!

[ShaniaTwain]

Yes, but if you use HTTP Request Snuggling you wont mind the extra packets.

Everybody likes snuggling.

Re:Problem reading the PDF...

[Anonymous Coward]

Here is a link:
http://www.gatech-edu.org/HTTP-Request-Smuggling.p df

Possible way to burn down RSS?

[krowten21]

Scenario: Vulnerable web server for popular blogging site, compromised by this or other attack, RSS feed used to broadcast exploit against vulnerable IE 7.0 clients. predicted at www.threatchaos.com att he beginning of the year.

Re:Possible way to burn down RSS?

[SpaceLifeForm]

Not just RSS. Are you sure that I read what you wrote?

Quick Summary

[MojoRilla]

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.

Re:Quick Summary

[wfberg]

Or to look at it another way;
crappy firewall/proxy software does a crappy job at parsing pipelined HTTP and allows people to get at banned content or to have their caches poisoned. You wouldn't expect them to do a half-assed job, as it's their entire purpose in life to make sure malicious traffic doesn't occur, so the least they could do is strict parsing.

Webservers do a better job of parsing HTTP headers, and where they fail, it just results in an additional request that's interpreted as per usual, so no vulnerability there, they're just serving up content they're supposed to serve.

Re:Quick Summary

[John Hasler]

...the least they could do is strict parsing.

And how many things do you think that would break?

Re:Quick Summary

[MooseGuy529]

Due to bad handling of borderline html

You mean HTTP, right?

Re:Quick Summary

[Anonymous Coward]

Due to bad handling of borderline html

HTML is a document format. HTTP is a communications protocol. If you confuse the two, you simply aren't qualified to summarise this article for laypeople.

This is due http keepalive (so that more than one request can be processed in a stream)

No, that's merely a secondary feature of the attack, not the root cause.

The basic problem is that some caching proxies get confused by multiple headers with the same header name. The trouble is that the caching proxy uses the first field value instead of throwing it away, and the server it is forwarded onto uses the second field value.

By doing so, you can, for example, make the caching proxy think that you are talking about one resource, while you and the server are actually talking about another resource. This means that you can trick the caching proxy into believing one response it gets from the server is appropriate for a different request.

There are other attacks outlined as well, but the root cause is the same. This isn't caused by "HTTP keepalive", it's merely a feature that is used in the attack, same as caching, headers, and a few other features of HTTP. None of that is the root cause, it's the multiple header handling being treated differently that is the root cause.

This seems to be implemented mostly by sending duplicate or invalid content length headers.

You have it completely the wrong way around. The duplicate headers are the cause, the multiple requests are merely an implementation detail.

All of these issues would be fixed by tighter HTTP parsing specifications.

According to the HTTP 1.1 specification, these are already invalid requests. How do you propose tightening up the specifications, by saying that they are ultra-really-really-invalid-I-promise requests?

Hype it up?

[Anonymous Coward]

This paper discusses potential exploitation of poor HTTP parsing in specific applications. Potential applications include cache poisoning and hijacking user credentials but it requires the victim to be behind a vulnerable proxy/firewall.

Why not just issue seperate advisories and inform the respective vendors? Seems to me like they bundled multiple flaws in multiple products so they could be creditied with discovering a new class of vulnerability.

Re:Hype it up?

[Sven Tuerpe]

Why not just issue seperate advisories and inform the respective vendors? Seems to me like they bundled multiple flaws in multiple products so they could be creditied with discovering a new class of vulnerability.

Because the whole point of this type of vulnerability is undesired interaction between different implementations of the same protocol. No single product will ever be vulnerable and each and every vendor might well point to the next one saying it's their fault.

Re:Hype it up?

[Anonymous Coward]

Exactly. This points out just how poorly most HTTP servers are implemented. Anyone foolish enough to run Tomcat, Apache, or any other of the open source, freeware crap that's out there deserves what they get.

publicfile

[sugarmotor]

http://cr.yp.to/publicfile.html, publicfiloe, is not mentioned.

Let me guess

[Anonymous Coward]

This will be PATRIOT ACT V (3 and 4 were allowed to be hidden from the public). It will be pushed by GWB and Tom Tancredo.

Interesting but will be patched soon

[Anonymous Coward]

It's an interesting find, pretty clever, but according to the whitepaper, it doesn't apply to all web servers in general (you need to know the specifics of all the machines involved) so its not a general problem. As well, it will probably be patched soon, so that it won't work. Once one of the machines involved in the HTTP chaining is fixed then it appears that the entire exploit no longer works.

Well this is not good

[suitepotato]

From TFA:

Conclusion: We have seen that there are many pairs (proxy/firewall servers and web servers) of vulnerable systems. Particularly, we demonstrated that the following pairs are vulnerable: PCCA o IIS/5.0 o Tomcat 5.0.19 (probably with Tomcat 4.1.x as well) Squid 2.5stable4 (Unix) and Squid 2.5stable5 for NT o IIS/5.0 o WebLogic 8.1 SP1 Apache 2.0.45 o IIS/5.0 o IS/6.0 o Apache 1.3.29 o Apache 2.0.45 o WebSphere 5.1 and 5.0 o WebLogic 8.1 SP1 o Oracle9iAS web server 9.0.2 o SunONE web server 6.1 SP4 ISA/2000 o IIS/5.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 DeleGate 8.9.2 o IIS/6.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 Oracle9iAS cache server 9.0.2 o WebLogic 8.1 SP1 SunONE proxy server 3.6 SP4 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 FW-1 Web Intelligence kernel 55W beta (the IIS 48K technique probably works with R55W) o IIS/5.0 This is a partial list - there are many pairs we did not test and there are likely many other web servers and cache servers we did not test for lack of hardware and software. Of course, there are probably many more similar techniques.

Yeah, really? I'd like to see a much broader list laid out, and preferably before it becomes another net disaster.

If this was strictly a Microsoft thing we'd be hearing cries for blood, or at least an app to check if your setup was vulnerable. Since it is much broader than that, if checking for this doesn't become part of a security toolkit, we may well wish it had.

Oh well. At least we got this much warning this much in advance. Anyone want to take bets on how long till some malware weasels make this a point and click thing in another script kiddie kit? My guess is before the security world makes a test app to check for it.

That's already what Apache does

[wtarreau]

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

Re:That's already what Apache does

[AndroidCat]

A HTTP request is supposed to end with a CR/LF. If that's not what's at the end of the Content-Length, perhaps the request should be dumped? (I'm too lazy to check the RFCs to see how binding that requirement should be.)

Working example available?

[pongo000]

The world is full of hypotheticals...can someone actually point us to a working example of this alleged exploit? If not, I'll just file it away as "cool information with little practical impact on my daily life."

Re:Working example available?

[failure-man]

Check back in twelve hours. Whoever feeds the script-kiddies is working on it I'm sure.

Side question: who feeds the script kiddies their "1337 h4x0ring t00ls" anyway? What's in it for them to give weapons to the little bastards? I assume it isn't for the money since I would think that an unknown exploit technique would be immensly valuable in that regard. Is it for the sheer destruction of the thing without the fingerprints?

Re:Working example available?

[slavemowgli]

RTFA.

Re:Working example available?

[qwijibo]

Giving the tools to the script kiddies keeps the noise ratio high. It's not too likely that someone is going to be able to keep a vulnerability as their own personal in, so by making the tools commonly available, it makes the random attacks indistinguishable from the targeted attacks.

Re:Working example available?

[Anonymous Coward]

Giving the tools to the script kiddies keeps the noise ratio high.

Er, your statement makes no sense.

Try: Giving the tools to the script kiddies keeps the background noise high.

Re:Working example available?

[Anonymous Coward]

he meant the noise level as in the signal to noise level. Don't be such a tool

Re:Prediction

[Anonymous Coward]

This is Slashdot, News for Nerds, not "your average bloke on the street".

Your post would make alot more sense if the article was mentioned on CNN.com or the like, but not here.

Mirror

[Anonymous Coward]

see here:

http://mstauffer.homeunix.net/markus/HTTP-Request- Smuggling.pdf

PCCA??

[d3ac0n]

Does anyone have any idea what the Popular Commercial Cache Appliance is? The PDF doesn't say and we have a few cache appliances at my office (intranet and internet). I'd like to know just vunerable we are to this type of thing.

Re:PCCA??

[Anonymous Coward]

Perhaps you should read the white paper and then test.

Re:PCCA??

[d3ac0n]

Umm... How would I even KNOW about PCCA if I HADN'T read the white paper? duh.

Re:PCCA??

[cyphersteve]

NetApp's NetCache.

obligatory question

[Anonymous Coward]

is this feature available only for windows? or is it platform independant?

Re:Old news...

[Anonymous Coward]

This post was brought to you by WebScurity.com.

Enjoy the new freedoms of the internet you receive when you utilize the amazing potential of WebScurity products!

Re:Problem reading the PDF...

[arose]

Do you have that over ftp? ;)

Re:Old news...

[Panaflex]

I wrote my own web server 5 years ago.. faster than Apache, cheaper than others. Doesn't have this problem.

-Pan

Re:Article Text -- Karma whoring????

[camusflage]

Not that it really matters, but my karma is just spiffy. Aside from a few dings here and there, made up for by accepted submissions and moderated posts, It's probably 50, or within a few points of it, as that's what it was back when they took away the karma scoring..

Re:Old news...

[JRHelgeson]

Bah, I'm a reseller who enjoys a product... is it so wrong to share it with people? I have no dog in this fight.

Re:Old news...

[Anonymous Coward]

go shove your bullshit babble up your ass.

"artificial intelligence engine" that "maps business logic".

fucking wanker.

Er... mods?

[Anonymous Coward]

This guy isn't talking about anything remotely related to the article, which is discussing a very specific type of attack. How in hell is that insightful? It's just plain old -1 RTFA.

patent blanket!

[matt me]

Can they not just patent the technique and then sue the pants off any hackers?

Tomcat workaround

[mparaz]

Use the connector (mod_jk) to let httpd handle the HTTP protocol and forward it to Tomcat (or Tomcat-embedding appservers such as JBoss)

Smuggling, eh?

[Aldric]

When will HTTP Customs be introduced as a fix?

Re:Old news...

[rbarreira]

Post us a link then, if you think it's worth it :P

Re:Old news...

[Anonymous Coward]

Go read the article. Apache, nor IIS is vulnerable on their own. The problem is interaction between proxy servers and webservers. Since yours cannot possibly act the same as all proxy servers, yours is just as vulnerable, though likely to a different subset of proxy servers than either Apache or IIS.

Re:Problem reading the PDF...

[shepmaster]

Very interesting... just curious, what is this URL? The WHOIS on this site and the 'official' gatech.edu webpage differ significantly, but the links on this page point to gatech.edu.

Is this some oddball splinter webpage, or what?

Yeah, but the guy is an *Israeli*!

[Anonymous Coward]

Everything they do has to be hyped up. It's the law or something.

how is this flamebait, exactly? (eom)

[subtropolis]

lamefilter: # Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

Re:how is this flamebait, exactly? (eom)

[Anonymous Coward]

"lamefilter: # Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)"

Me too!

Re:Problem reading the PDF...

[Anonymous Coward]

It is a joke, read the first article ;)

Re:Old news...

[julesh]

As I read it, his server could be secure if it drops the HTTP connection whenever it receives a malformed request. Also, any server that doesn't support keep-alive is not going to be affected by this.

"Be liberal in what you accept", but not a slut!

[JohnQPublic]

The fault here lies with broken HTTP implementations, not with the protocol or with interactions between compliant implementations. Taking just the first example from the paper, any implementation that receives 2 "Content-Length" headers should reject the request because it's an illegal format.

Content-Length: 0[CRLF]
Content-Length: 44[CRLF]

is exactly the same as

Content-Length:0, 44

by the multiple-header rule (RFC 2616 sec. 4.2), but Content-Length doesn't allow multiple values (ibid sec. 14.13). In this example, both the proxy and the webserver are out of spec and should (at a minimum) discard the blue-and-purple request, and should probably close the connection and ignore the red request was well, since the body of a POST cannot be of indeterminate size.

Re:Problem reading the PDF...

[ady1]

google cache of the pdf http://64.233.187.104/search?q=cache:TWK7qyxXeYIJ: www.watchfire.com/resources/HTTP-Request-Smuggling .pdf+&hl=en