Stay in touch

Enter your email and get the latest news and researches on cybersecurity, receive invitations to private security events and conferences.

XSS: the easiest way to hack your website in 2014

Thursday, November 20, 2014

There is no need to convince people that XSS was, is and probably will be the most frequent web vulnerability. However, many people, including security engineers, team leaders and web developers, still seriously underestimate the impact of XSS and its consequences. In this blog post, we will try to reveal the most commonly ignored risks of XSS vulnerabilities.


Introduction

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 try to reveal the most commonly ignored risks of XSS vulnerabilities. The numbers and statistics you will see below mainly come from:



Some quick facts and numbers 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/frequent web vulnerability:
  • Trustwave’s Spiderlabs estimates that “82% of web applications are vulnerable to XSS” (2013).
  • WhiteHat Security report says that “XSS regained the number one spot for being the most common vulnerability” (2014).
  • Cenzic confirms that “XSS leads the [most popular vulnerabilities] list in terms of frequency of occurrence” (2014).
  • 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” (2014).

Since Q1 2012, High-Tech Bridge Security Research Lab 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 opportunities for hackers and ignored risks

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 any 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. Such passive XSS attacks are very dangerous as they do not require to send anything to the victim, neither to trick to click any links, it's enough just to backdoor a website that the victim regularly visits and wait for 1 or 2 days.

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:

  • 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 of 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 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 on live websites are XSS inside JS code, and therefore cannot be blocked by WAF.

People ignore security best practices making XSS easily exploitable

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.

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.

Solutions

It is difficult to propose something new, but here is the list of basic security precautions one shall take to avoid website compromise via XSS vulnerability:

  • Explain to you web developers that one XSS vulnerability may lead to total compromise of the entire company.
  • Make sure your web developers and server admins respect security best practices. This will already resolve majority of potential problems.
  • Make sure that your IT team has a clear inventory of your web resources, that there is no abandoned or test web projects that are accessible from the outside.
  • Never rely on your WAF as the sole security solution aimed to prevent all types of attacks.
  • Regularly conduct web penetration testing by independent companies.

Ilia Kolochenko, High-Tech Bridge's CEO, comments: "SQL injection vulnerabilities are becoming more and more rare, as well as other high and critical risk vulnerabilities. They are complex to detect and quite often requires a lot of time to exploit. At the same time almost nobody cares about "medium-risk" XSS vulnerabilities leaving their websites vulnerable. Obviously, hackers benefit from such negligence and use XSS vulnerabilities to achieve their goals. If you close your door, don't forget to close your windows - otherwise the entire security is at risk."


User Comments
Add Comment