Today, there is no need to convince people that XSS (Cross-Site Scripting) was, is and probably will be the most popular web application vulnerability. However, many people, including security engineers, team leaders and web developers, still seriously underestimate the impact of Cross-Site Scripting vulnerabilities and their consequences.
Ignorance of XSS vulnerabilities is also indirectly confirmed by the “XSSPosed.org” website, an open Internet archive of web vulnerabilities. The website contains about 6,000 XSS vulnerabilities, including vulnerabilities on Google PR 10 websites, Alexa Top-100 websites, websites of security companies, governmental and media websites. Many of the vulnerabilities are still unpatched.
In this blog post, we will to reveal the most commonly ignored characteristics of XSS and try to dispel some misunderstandings about XSS. The research data comes from:
– ImmuniWeb® on-demand web application penetration testing SaaS
– High-Tech Bridge Security Research Lab
– Ongoing computer forensics projects performed by High-Tech Bridge.
In total, during the last 24 months we have pen-tested over 1,000 high-profile live websites, audited more than 150 well-known web applications (used on average by 5,000 live websites [per application]), and investigated over a dozen of high-profile web hacks targeting several millions of users.
Some existing facts and figures about XSS
XSS vulnerabilities have been actively exploited by cyber-criminals for almost a dozen of years already. OWASP describes XSS as “the most prevalent web application security flaw“, security companies and organizations frequently mention XSS as the most common/popular web vulnerability:
– Trustwave’s Spiderlabs estimates that “82% of web applications are vulnerable to XSS”.
– WhiteHat Security report says that “XSS regained the number one spot for being the most common vulnerability”.
– Cenzic confirms that “XSS leads the [most popular vulnerabilities] list in terms of frequency of occurrence”.
– CWE by MITRE warned about the problem in 2011 saying that “XSS is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications”.
Since Q1 2012, High-Tech Bridge Security Research Lab has released 169 security advisories covering 161 well-known software products, 56% (91) of which contained XSS vulnerabilities. 96% of the vulnerabilities were patched by vendors thanks to our efforts and assistance, but XSS vulnerabilities are often live for a long time before being identified or patched.
XSS: great hacking opportunities, ignored risks, and compromised web applications
In this section we will briefly overview the most common properties of XSS attacks and the opportunities they give to attackers, many of which exist since years but are still seriously underestimated or even ignored by the web developers community.
XSS does not require much social engineering or interaction with humans
Yes, unlike SQL injections for example, XSS is only exploitable if the attacker can trick a user into opening a malicious link to trigger the vulnerability. Many people think that hackers send you a 200-character URL with the XSS payload inside that any antivirus will block, and that an experienced user will never ever think to open.
In fact, XSS vulnerability can be exploited by making the victim visit any page of any website where the attacker can place an XSS exploit. AJAX functions allow attackers to steal cookies (or perform any other XSS exploitation) from any website the attacker controls, the victim doesn’t need to open the vulnerable website in a browser window. Of course, the attacker needs to have a write access to the website with the XSS exploit, but today it’s pretty easy to compromise one famous website among the dozens or even hundreds that the victim regularly visits and trusts.
It’s enough to make small change to the index page of the website [controlled by the attacker] in such a manner that if IP address of a visitor belongs to the victim’s subnet (e.g. network of a bank) the index page will automatically inject an XSS exploit among other HTML content. Such attacks are extremely difficult to detect, and even IT security professionals can be easily compromised via such technique.
Another pattern that we regularly see on the market is using XSS vulnerabilities (especially stored ones) to deliver malware to the victim, instead of just stealing credentials. By clicking what appears to be a trustworthy link the victim becomes not only a victim of data theft via XSS, but is also entirely compromised.
Quick facts:
– Seven out ten web investigations performed by High-Tech Bridge involved XSS usage aimed at infecting users with malware.
– Over 90% of XSS vulnerabilities can be exploited in such a manner that even advanced users and IT people will not suspect anything.
– The structure and architecture of over 70% of web applications allows creation of a sophisticated XSS exploit that will perform several fully-automated consecutive actions, giving full administrative access to the attacker at the end.
– More than 95% of XSS vulnerabilities can be used to perform sophisticated drive-by-download attacks infecting users who just open a harmless-looking URL they trust.
– SSL certificate and HTTPS connection to the website have absolutely no impact on web application security and can never prevent XSS attack.
XSS on a subdomain puts the entire web application at risk
Many large companies install expensive web application firewalls (WAF) and regularly conduct penetration testing for their main, most critical website. At the same time they ignore security on numerous subdomains that they consider “less important” for business continuity. The problem is that in many cases, for the sake of simplicity, usability and compatibility, cookies installed on the main website (e.g. www.site.com) will be valid for any subdomain like (education.site.com or jobs.site.com). This means that an XSS vulnerability on a test, or forgotten, subdomain may be easily used to steal cookies from the main website, or from the other subdomains (e.g. e-banking.site.com that also sets cookies for *.site.com), even if they are located on completely different servers in different datacenters. Quite often, particularly in large companies, different departments have their own websites and subdomains for testing reasons which are not designed to be secure, but their presence endangers the entire web infrastructure of the company. We are not even talking about the case when test area is located directly on the main website (e.g. www.site.com/secr3t/beta1/) but can be found by Google search.
Quick facts:
– Over 80% of websites set cookies in such a manner that they are accessible for several, or even all subdomains.
– Over 90% of large and reputable websites have subdomains with XSS vulnerabilities.
A WAF does not protect against XSS vulnerabilities anymore
Web Application Firewalls are a common way to protect sensitive web applications. However, a WAF should never be used as the sole security measure to keep web applications secure. Web applications continually evolve: new features and functions are being regularly added and updated, while HTML5 brings new functionality. All these factors cause WAF rulesets to become outdated quite quickly and allow hackers to bypass them. Particular attention should be given to the web applications where user-supplied input is being inserted into JS code: it gives the attackers unlimited opportunities to obfuscate the XSS payload and thus to bypass any WAF.
Quick facts:
– Over 70% of existing WAF rulesets can be bypassed via XSS obfuscation techniques.
– Around 30% of XSS are XSS inside JS code, and therefore cannot be blocked by WAF.
Insecure session management, cookies accessible via JS and server misconfigurations make XSS attacks very easy
The majority of web applications, that use sessions in cookies to identify users, rely on insecure mechanism for session creation and management. The session is not bound to a unique user identifier, such as his IP address for example, and if the session is stolen via XSS attack – it may be reused by the attacker to get into the system under the user’s account. Web developers tend to ignore best practices, such as using httpOnly cookies that cannot be accessed via JavaScript. Of course, httpOnly cookies do not prevent all vectors of XSS exploitation, but significantly reduce the risk of data theft stored in cookies. However, even the httpOnly cookies are useless if the web server supports the HTTP TRACE method, which allows attackers to read httpOnly cookies bypassing the restriction. Insufficient session expiration is another big problem today that is also listed among the OWASP Top 10. It simplifies XSS attacks a lot: even when the user logs out from the system, his session will remain valid and allow hackers to surf under the victim account until the victim comes back. But remember that in the case of fully-automated XSS exploit usage, a dozen of seconds may be perfectly enough to get total control over the victim’s account.
Quick facts:
– 85% of websites do not bind user sessions to user IP addresses, nor do they conduct proper session management.
– 80% of websites do not use httpOnly cookies.
– 40% of websites with httpOnly cookies allow the HTTP TRACE method.
A single XSS vulnerability renders CSRF protection mechanisms useless
Almost any web application gives great access and privileges to its administrator: from arbitrary SQL command execution to arbitrary file upload and arbitrary code execution. Administrative interfaces usually don’t have the numerous security mechanisms that are present in the standard user interface, as the administrator is commonly considered as a trusted party that won’t harm his own website. Modern web applications have cross-site request forgery (CSRF) protection in order to prevent malicious usage of sensitive website functionality in the case of a CSRF attack. However, a single XSS can bypass CSRF protection in the majority of cases and allow a remote attacker not just to steal sensitive data, but also to act as a privileged user or even administrator of vulnerable web applications – significantly increasing the impact of XSS attack.
Quick facts:
– Over 95% of CSRF protection mechanisms can be bypassed via XSS vulnerability on the same site.
– Architecture of over 70% of websites gives almost unlimited functionality to administrator that can be used by hackers to compromise the entire website and even the web server.
