Re: [Webappsec] Tacking A Difficult Problem - Solutions HTTP Response Sp
Re: [Webappsec] Tacking A Difficult Problem - Solutions HTTP Response Sp
[Amit Klein]
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.&
Scanner Jockey: ...
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
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 disagr-)
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 ()? 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
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,
&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
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.
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)?
-------------------------------------------------------------------------
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!
--------------------------------------------------------------------------
Current&Thread
, Amit Klein
Message not available
Message not available
, Amit Klein
Message not available
Re: [Webappsec] Tacking A Difficult Problem - Solutions HTTP Response Splitting,
Amit Klein&&=
Message not available
, Amit Klein
Previous&by&Date:&
, Amit Klein
Next&by&Date:&
, Amit Klein
Previous&by&Thread:&
, Amit Klein
Next&by&Thread:&
, Amit KleinWeb Security Lens | Pentest web applications in depth
Adopting third-party libraries to encode user input in the development phase and using a web application firewall in the deployment phase could fool web security managers into thinking their web applications are completely safe from Cross-Site Scripting (XSS) attacks. While it’s a good idea to employ these techniques, the illusion of safety could prove costly. These protection methods do not guarantee that your web applications are 100% free of XSS vulnerabilities, and XSS attacks that use more sophisticated techniques still occur, so care should still be taken.
In the past several months,
and patched two critical XSS vulnerabilities.
These clearly show XSS vulnerabilities continue to occur in modern and mature web applications, even for Internet companies. The XSS vulnerability in Yahoo email was straightforward: the input validation was not robust enough to escape malicious code, and the attacker was able to break input validation. The one patched by Facebook was a little trickier because it exploited a bug in the file upload function to upload malicious JavaScript code and then invoked the code by calling it from a different application. Just this week as I was finishing this blog post, an insufficient input validation XSS vulnerability was disclosed in the popular WordPress plugin.
As I have observed from my work experience and as a bug bounty hunter, XSS vulnerabilities are definitely not going away — and many attacks are getting more sophisticated. The golden age of penetration testing, when pen testers could discover XSS vulnerabilities simply by inputting malicious code into a search box, is over. It often takes more skill and effort for webmasters to discover the XSS vulnerabilities they need to protect against.
XSS Hidden by Web Application Firewalls
Web application firewalls (WAFs) are commonly used to protect web applications. They are indeed effective in blocking a large number of web attacks. Some pen testers give up immediately when they determine the web application is deployed behind a web application firewall. However, a WAF is just like a cast that by itself does not fix the broken limb. And like a cast, a WAF is best used as a temporary protection until the underlying issue, in this case a coding error, is fixed and redeployed.
Instead of fixing the issue, WAFs just hide XSS vulnerabilities and makes it harder for attackers to exploit them, wh but WAFs also makes it more difficult for penetration testers or automatic scanners to discover these vulnerabilities. According to the , over 70% of existing WAF rulesets can be bypassed through XSS obfuscation techniques. As a rule-based tool, WAFs trap the main cases for which rules are defined, but not all of the corner cases — the development effort spent to make the perfect ruleset would be better spent fixing the underlying coding error.
Recommendation: When running a security audit, e.g. via automated tools or penetration tests, always disable your WAF so that the XSS vulnerabilities can be discovered to the greatest extent. You want to make it easy on yourself to find XSS vulnerabilities, so you can fix them in your code.
In my work, I have seen many examples where customers claimed that
(WAS) had generated false positives, when in fact they were true positives but the customer didn’t see the exploit because they were protected by a WAF. In these cases, I could often exploit the XSS anyway by coding exploits that bypassed the WAF protection.
Example: Methods to bypass WAF could be found on the Internet: Using escape sequences (%00onload%00=%00) ins or an alternative XSS method, such as, payload document.body.outerHTML=maliciouscodes could be used to break some WAFs.
More Sophisticated XSS Attacks
Three types of sophisticated XSS attacks are difficult for pen testers and tools to discover. It is not easy to propose new techniques to combat these, except enhancing security implementation during web development and employing a DAST (dynamic application security testing) tool for regular security audits to make sure you catch any that were inadvertently included in your code.
DOM-Based XSS
Attacks against DOM-Based (Direct Object Model) XSS vulnerabilities modify the client side DOM tree in the victim’s browsers an as opposed to a traditional XSS vulnerability which exploits the server side code. DOM-based XSS vulnerabilities are harder to detect than the traditional XSS vulnerability because they resides in the script code from the website and the injection payloads are not reflected directly in the response. It has been estimated that 30% of XSS attacks on live websites are XSS inside JavaScript code and cannot be blocked by a WAF. Due to the difficulty of discovering them, DOM-based XSS vulnerabilities become a blind spot for many scanning tools and penetration tests.
Example: Here is the normal format of a DOM-based XSS attack vector
http://www.some.site/page.html#name=&Malicious-JavaScript-Code&
Multiple Step XSS
Multiple Step XSS vulnerabilities require the user to perform several actions on the applications to execute the attack vector/injected malicious JavaScript code. The main characteristics of multiple step XSS vulnerabilities are that the attack vector is injected in one page and then echoed in another page or application later. Due to this factor, it creates a challenge for penetration tests or ordinary DAST tools to identify this kind of vulnerability.
Example: Qualys WAS reported a XSS vulnerability in a customer’s application. The customer’s security team claimed they could not find the injection point and wanted to flag it as a false positive. After investigation, we found the injection point was from a different subdomain and the malicious code was invoked by making a search with a keyword matching with the malicious code injected in the response.
Path-Based XSS
Targets for Path-Based XSS attacks are applications where the request URLs are rendered directly in the response body without proper encoding or input validation. The following source code snippet is a model demonstrating how path-based XSS vulnerabilities reside in your web applications.
&a href=" &?php echo $_SERVER['REQUEST_URI'];?&"&Click Here&/a&
Example: Path-Based XSS vulnerabilities are a special breed but it is not rare. I have discovered and some other open source web applications. Meanwhile, multiple path-based XSS vulnerabilities were flagged in our clients’ web applications. The attack vector looks like:
Conclusion
While WAFs are a great protection measure against attacks on vulnerabilities resulting from coding errors that you have not yet fixed and deployed, you should always disable WAFs for internal testing. This helps ensure you don’t inadvertently overlook any simple XSS vulnerabilities in your code. It’s always safer to fix the underlying vulnerability than to rely on a WAF for long-term protection.
In addition, developers should take care in their coding to look for the more subtle XSS vulnerabilities, since we are regularly finding attacks that try to exploit these.
This entry was posted in
Ebay add me in its hall of fame after I reporting a clickjacking related issue for them
/securitycenter/ResearchersAcknowledgement.html
This entry was posted in
Recent Posts
Categories