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

[Amit Klein <aksecurity () gmail com>]

Arian J. Evans wrote:
> Amit -- your paper, like all your papers, is well researched and 
> brilliantly
> written. Your responses, discussed in your paper, are all excellent points
> but are not the point(s) I am making on HTTPRS and PCI:
>  
> 0. Read Amit's paper closely (for those reading who haven't).
> 1. It (HTTPRS) is *highly* conditional. Sometimes multiple 
> concurrent conditions.

I disagree here. At least one result of HTTP Response Splitting, 
XSS/browser cache poisoning needs a minimal set of preconditions (beyond 
the vulnerability itself). It needs IE (but may be possible to 
accomplish on other browsers - I didn't try). It can work over HTTPS 
(and HTTP, of course), and doesn't need intermediary. So at the minimum, 
having HTTP Response Splitting vulnerability implies having an XSS issue 
in the site.

> 2. Evalutuate those *conditionals* and discuss with your PCI vendor.
> 3. Those conditions may be outside the scope of PCI.
> 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.
> My experience is that almost no one I speak to understands HTTPRS
> and the conditionals in your paper, Amit, off of these lists.

Sadly, I tend to agree...

>  
> Same for the Flash attack vector; if you need existing headers,
> then there are some limitations here too.

I need Content-Length, which I demonstrated with Flash 7/8 - Flash 
happily let me overwrite. In Flash9, my original technique doesn't 
apply, but Rapid7 showed that it's possible to override Content-Length 
via a more advanced trick (http://download2.rapid7.com/r7-0026/).

>  
> 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.
>  
> You can CSRF to XSS (a'la Nokia/appliance stuff in my old
> examples) or XSS to CSRF (a'la Jeremiah's demos) or you
> can simpy embed scripts and let them fly, same site, cross
> site, whatever... The caveat(s) in most cases is (1) must have
> computer with (2) web browser with (3) script enabled.
>  

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.

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