Re: [Webappsec] Tacking A Difficult Problem - Solutions HTTP Response Splitting

[Amit Klein <aksecurity () gmail com>]

Arian J. Evans wrote:
> Every example I hear is either proxy-related (and still 
> misunderstood), or goes exactly like this:
> Scanner Jockey: "Looks like your site is vulnerable to HTTP RS"
> Q: "What does that mean?"
> Scanner Jockey: "It means an attacker could split the HTTP response."
> Q: "What does that mean?"
> Scanner Jockey: "It means that like, man, I could like add a cookie or 
> control your browser man."
> Q: "How?"
> Scanner Jockey: ...
> <Blink>

Okay, I think I understand what scanner folks mean. The thing is, HTTP 
Response Splitting can be viewed as a special case of a wider attack - 
HTTP Response Header injection. Through the latter attack, you can 
inject a Set-Cookie header, or an entire HTTP response body (think XSS - 
I guess this is the "control your browser" part), so there's meat to 
this argument.
So what do you need HTTP Response Splitting with this condition, you 
might ask? well, if you have IE getting an injectable 302 response, then 
it doesn't parse the response body (no XSS for you by merely injecting 
the body). Or you want to conduct browser cache poisoning - for both, 
you need the full HTTP Response Splitting attack.

> I'll try to test some different browsers next week for local caching 
> attacks. I'm still not seeing the surface on that.
>
>     > 4. Those conditions may not at *apply to you at all*.
>
>     Theoretically - yes. Practically, since it's hard for a site owner to
>     verify that NO set of preconditions apply, I think it's better to
>     assume
>     the attack is feasible.
>
>
> I can't agree with you at all on the assumption that the situation is 
> exploitable. The attack landscape on this is pretty quiet. There's 
> plenty of attacks yet to tip, that will tip long before this does. 
> </prediction>

I have to disagree to this argument ;-)

First, there's the difference between whether the attack is feasible and 
whether it has been exploited before. I don't see why the latter matters 
much. If a vulnerabilty exists, we need to assume it may be exploited. 
It matters whether the vulnerability is known (it is), how hard it is to 
perform it (not trivial, but then again, not science fiction too), and 
what can be gained (quite a lot, depending on the exact configuration).

Think about SSL - I think cases where HTTP traffic (vs. HTTPS) was 
sniffed in order to conduct an attack are very rare. Yet any auditor in 
his/her sane mind would flag no-SSL site (assuming it's of value) to be 
a vulnerability.

Or consider XSS - how many attacks were made using this vector in the 
first years (2000-2004)? But in 2005 (if I remember correctly) we had 
some XSS worms and the whole XSS business warmed up.

>     > I didn't grok your XSS rebuttal. Not to equivocate, since we
>     > lump an entire bucket of "arbitrary script injection" under XSS,
>     > but I don't see that at all unless you mean reflected XSS.
>     [...]
>     I was referring to non-persistent XSS, which is a special kind of
>     CSRF.
>     According to your original post, if I need the client's browser to do
>     something for me, it's already CSRF (so, if I'm reading correctly,
>     it's
>     "not interesting"). Yet non-persistent XSS requires exactly that. 
>
>
> Okay, we are in complete agreement here then. I painted with too
> broad a brush in sweeping that aside. Thank you for being polite,
> considering two of these items are your children. :)  (CSRF and AS 
> checks)

CSRF? you probably mistake me for someone else...

AppScan checks - yep - been responsible for the AppScan content (rules) 
for several years, together with Ory Segal. But I'm not there for the 
last 2.5+ years.

> <OT>
> So when are we going to beat the "let's re-valuate the non-persistent
> XSS attack surface" drum? Is the email attack vector drying up?

But what about the malicious sites (hence the original name XSS)?

-Amit

-------------------------------------------------------------------------
Sponsored by: Watchfire

Cross-Site Scripting (XSS) is one of the most common application-level 
attacks that hackers use to sneak into web applications today. This 
whitepaper will discuss how traditional XSS attacks are performed, how to 
secure your site against these attacks and check if your site is protected. 
Cross-Site Scripting Explained - Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008fHA
--------------------------------------------------------------------------