Share this article
Cross Site Scripting, or XSS, is one of the most common type of vulnerabilities in web applications. XSS attacks are nothing new. They have been a part of the OWASP TOP 10 most critical web application ranking since its creation and were even at the top of the list in 2007. Cross Site Scripting vulnerabilities aim at injecting malicious content or functionality in websites, which affect the visitors or users of the website rather than the application itself directly. While the threat is known, the problem remains. For instance, in the fourth quarter of 2017, XSS still accounted for 8 % of all web application attacks according to an Akamai report. In this first, brief introduction, we will look at what an XSS is, and some more significant examples of attacks.
XSS is an incredibly common vulnerability, and while often appearing trivial, through modern exploitation techniques it can be used in a range of ways: from acting on behalf of application users, stealing identities in the application, redirecting traffic or even introducing fake content into a corporate website. Just as other exploits that have developed over the years, counter-measures have also been added (for example modern browsers which protect cookies). Unfortunately, attackers have adapted themselves too.
There are three different forms of XSS sub-classes of vulnerabilities:
- Reflected XSS: This is the most common XSS vulnerabilities which occur when an internet user makes a request, and the server does not send back a safe response to the browser. The attack is only active during that specific request, requiring the attacker to find a means of distribution, for example via email, or links from other websites. The danger is that an attacker can convince a user to follow a prepared URL that injects code into the returned page, giving the attacker control over the content of that page. It can lead to the attacker stealing the user's identity, introducing fake content into the website or, for example, changing the login function to send usernames and passwords to the attacker instead of the application.
- Stored XXS: Indifference of the reflected category which requires an external means of delivery, the Stored or Persistent XSS is the result of user input stored in the application. Stored XSS have the same impacts as reflected ones, with the difference that an attacker can place those into the application and then do not have to distribute the attack to any potential victims actively. If this occurs in a jam-packed website page, the distribution will be fast and have a high impact.
- DOM XSS: DOM, or “Document Object Model” is the representation of a website in within a browser. It is changed and modified by dynamic content, and via vulnerabilities in those modifications. The DOM-based attacks do not need to interact with the web server, making traditional active defenses, such as web application firewalls, useless.
XSS attacks are used to hijack an account, steal sensitive data, such as user credentials or commercially valuable data. The attacks can also be used in so called “virtual defacements,” meaning an attacker can, for example, use it to display a different logotype, replace the entire content of the website as seen by a visitor or even introduce fake content into online newspapers. Most of the time the possibilities are only limited by the creativity of the attacker.
For example, Cross Site Scripting attacks were used against Myspace social network, in several incidents affecting Twitter and for a massive attack against eBay in 2014. eBay was initially hit by other attacks, leading to user information exposure. Those attacks were followed by a wide exploitation of an XSS vulnerability allowing attackers to steal user details repeatedly. Although being awarded of those vulnerabilities, the eBay website has still been reported to suffer from other XSS vulnerabilities recurrently in 2017.
How Cross Site Scripting works
Cross Site Scripting is, like many other attacks against web applications, an attack that occurs from the transition from a context where data is safe, to a context where it is interpreted incorrectly. As a result, by adding content to the website, a user can gain control of how the application behaves for other users.
The important part to remember is that the prerequisite for the attacks to work is that a user, or the user browser, provides input to an application. This input is either immediately or later sent to another user as part of a response.
As an example, we will instead of looking at the code, which quickly grows confusing, create a case where employees can fill in their names, and the salary team will then fill in their salary amounts. A creative user, Bob, decides to cheat the system. The output to the payment provider is automatic. In the database, all looks good, but when the paperwork is submitted to send out the paychecks, things change rapidly.
As you can see on the example above, the users changed the name is now submitted in a later output. Here it is interpreted in a very different way and would result in Bob getting ten times his intended paycheck.
One of the dangers of an adequately executed Cross Site Scripting attack is that to the user, nothing looks different, the behavior changes under the hood of the application.
The difference is, for example, that instead of submitting the login information to the website, the user will send its account information to the attacker website which would store the data.
Cross Site Scripting on OWASP Top 10
XSS has been part from the start of OWASP TOP 10:
- 2004 - Rank 4
- 2007 - Rank 1
- 2010 - Rank 2
- 2013 - Rank 3
- 2017 - Rank 7
As can be seen, Cross Site Scripting is ranked A7 on the last OWASP top 10. Its ranking decrease from the 3rd place in 2013 but even the risk tends to diminish according to the organization; this is mainly due to technical defenses in browsers protecting users' sessions. It should not be seen as a decrease in the number of vulnerabilities discovered. In fact, according to Security Boulevard, the number of reported XSS vulnerabilities have almost tripled in 2017. 630 vulnerabilities related to XSS were published on various vulnerability newsfeeds and user groups in 2016 compared to 1863 in 2017. The same study said that XSS represented 8% of the 2017 cyberattacks.
In the 2017 ranking, OWASP estimates the Cross Site Scripting exploitability is high and the prevalence and the detectability as difficult: "XSS is the second most prevalent issue in the OWASP Top 10 and is found in around two-thirds of all applications". Finally, according to OWASP framework, Cross-Site Scripting impact is "moderate for reflected and DOM XSS, and severe for stored XSS". As Cross-Site Scripting attacks allow full control of user access to a system, the reason why the impact is moderate is due to the difficulty of distributing the attacks to other authenticated users. But if an attacker can solve the problem of distribution, or attack a sufficiently well-frequented application, the problem no longer exists. For any user, the impact of getting successfully attacked will always be high.
How to avoid Cross Site Scripting (XSS) vulnerabilities
- As Cross Site Scripting vulnerabilities occur due to output from an application to its users, the primary way to prevent exploitation is by applying input and output sanitation. The only way to build a robust application is to ensure that such filtering is applied when data is transferring from one state to the other, for example inclusion from a server response or reading from a database.
- A good basic hygiene and security culture which promote security values is essential. One of the first things, that already should be a reflex for security teams, is to follow the best security practices: code rigorously, segment your network and control accesses to it, educate your teams on security (such as not to open suspicious email, do not share credentials and DO, enable multi-factor authentication). Check and assess your network, look for vulnerabilities and patch when you identify any. For developers, follow the OWASP prevention documents and the best security practices.
- DevOps can mitigate XSS efficiently using frameworks specifically designed to escape Cross Site Scripting, such as the OWASP ESAPI. It is also advisable to deploy a restrictive content security policy (CSP) as a defense in depth mitigation. For a dynamic application with frequent releases, it is imperative to have a continuous security program in place including an audit of the application, like our Appsec Scale and SWAT solutions integrated for example.
- Despite your efforts, if you do maintain a large set of application, you will continue to suffer from multiple XSS and other vulnerabilities. The better way to manage your network and application security is to do vulnerability assessment and have a security solution adapted to your need and your infrastructure. Ideally, the security solution will continuously monitor your network, alerts you when a vulnerability is detected and provide guidance for remediation. You can also be helped by cybersecurity professionals.
- Once basic security and routines are in place, for business-critical applications there is also the extra step to audit applications using penetration testing (Ethical hackers). Those are doing a great job by acting like hackers to show you all your network security flaws, and they can add human intelligence and potential target vulnerabilities in ways not possible for a security scanner.
Cross Site Scripting vulnerabilities are well known, easy to exploit but also easy to detect and to remediate so do not fall into the trap. If you want help and to know more about your security level, contact us. And discover now our web application security solutions to protect your network.
Application security is a complex subject. Our teams are also at your disposal to perform audits and allow you to find the best solution for your needs and cybersecurity budget.