Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: [Webappsec] Tacking A Difficult Problem - Solutions

Subject: Re: [Webappsec] Tacking A Difficult Problem - Solutions
Date: Fri, 20 Apr 2007 10:56:19 +0200
Hi Arian

Arian J. Evans wrote:
4.1. Turn off the HTTP Response Splitting check. Explain to your PCI auditor that you have no intermediary proxies (do you, eh?).

I assume the site is public. So what about forward\transparent proxy servers, which many clients have to use in order to access the web?


What about internal appliances (e.g. load balancers) that effectively act as HTTP proxies (not necessarily caching)? these may be subject to cross-user attacks and page hijacking attacks described in the HTTP Response Splitting paper (http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf) - pages 22-23.
Ask them how they intend to get the victim browser to make 2 HTTP requests w/out client side code execution. Yes, we call that XSS or getting the victim browser to run malicious code from your malware site.

If this is a public site, and people access it through a forward proxy (as I've seen several ISPs, universities, etc. force their clients to do), or a transparent proxy (ditto), then the attacker doesn't have to run malicious code on the client - the attacker can mount the attack directly, through the proxy (assuming the attacker has "legit" access to the same proxy). That's assuming at least one of the vulnerable scripts can be accessed over port 80 (non-HTTPS).


Moreover, even if the attacker cannot access the proxy server (or the whose site must be accessed over HTTPS), HTTP Response Splitting can be used to elevate an existing XSS problem into something bigger (see the paper, pages 21-22).


Sure you can split the response. But what exactly are you going to do with the second one?

You can do XSS. See the paper - p.4 and pages 19-21.

If you can split the response, get the victim browser to make the 2nd request and get the browser to chomp on the split response, then you are already XSSing or CSRFing or SessionFixating or SessionHijacking etc.

By this argument, any XSS vulnerability doesn't count, because it's based on CSRF...


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

<Prev in Thread] Current Thread [Next in Thread>