How to identify Cross-Site Scripting (XSS) vulnerabilities?

Cross Site Scripting, or XSS, is one of the most common type of vulnerabilities in web applications. XSS 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 script based attacks.

XSS attacks

XSS is an incredibly common vulnerability in web pages, and while often appearing trivial, through modern exploitation techniques it can be used in a range of ways: from acting on behalf of application user input, 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, despite numerous counter-measures (for example modern browsers which protect cookies), attackers continue to evolve their techniques and find new ways to exploit XSS.

There are three sub-classes of the XSS vulnerabilities:

• Reflected XSS: This is the most common XSS vulnerability 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 i.e. fake news. Most of the time the possibilities are only limited by the creativity of the attacker.

For example, Cross Site Scripting attacks were used against British Airways in 2018 by Magecart hackers, resulting in huge GDPR fines. It also steal private data of 200 million players on an unsecured Fortnite webpage, and 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 most common form is by the introduction of JavaScript in the responses (in forms, formatted responses need), but this can also be done via the addition of any other active components such as Silverlight or Flash to name a few.

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.

The same issue is occurring in web applications, but in those cases, user provided data is interpreted as JavaScript or HTML by web browsers, and hence allow the attacker control of the application in the browsers.

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 decreased 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

1. 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. 
2. 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 secure coding practices.
3. 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.
4. 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 needs 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.
5. 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.

Cross-Site Scripting (XSS) FAQ

1- How does Cross-site scripting work?

Cross Site Scripting, or XSS, is one of the most common types 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 affects the data and inputs of visitors of the website rather than the application itself directly. 

2- How can you avoid XSS vulnerabilities?

• Apply input and output sanitation

To prevent exploitation is by applying input and output sanitation. The only way to build a robust application against XSS is by ensuring 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.

• Apply secure coding practices

It’s essential for businesses to support their workforce to understand the importance of security awareness in their day-to-day working activities (such as not to open suspicious email, do not share credentials and DO, enable multi-factor authentication). Identify and test your network infrastructure for vulnerabilities with a risk-based approach and prioritize patching for imminent threats. For developers, follow the OWASP framework and applying secure coding practices throughout the SDLC.

• Use Appsec Scale and SWAT solutions

• Perform a vulnerability assessment

Implementing regular vulnerability assessments and utilizing threat intelligence tooling to highlight imminent threats of cyber attacks on your business is security best practice. A complete vulnerability risk management solution will help you sift through the vulnerability noise and prioritize patching, to save valuable time and reduce risk. A robust security solution will continuously monitor your network and alerts you when a vulnerability is detected and provide guidance for remediation. 

• Audit applications using Penetration Testing

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). This replicates a real-life attack scenario utilized attack paths from a hackers perspective to spot hard-to-reach vulnerabilities which could increase your risk of data breach. Pen testers will add a human lead test and target vulnerabilities in ways not possible for a security scanner.

3- Why is cross-site scripting dangerous?

Malicious cross-site scripting web vulnerabilities are very dangerous and can impact businesses through exfiltration of critical data leading to regulatory fines and damaged brand reputation. If XSS vulnerabilities go unnoticed it effects visitors every time they use the web page

4- What is an XSS attack?

Cross-Site Scripting (XSS) attacks are a type of malicious code inputted into a web page by hackers. The attacker aims to execute malicious scripts in a web browser of the victim by including this code when the user visits the web application and gain access business critical information and data

5- What is the main cause of XSS vulnerability?

XSS vulnerabilities are caused by malicious code that includes data in an HTTP response from an exposed web application. XSS exploits occur when an attacker causes a user to supply content to an insecure web application, which is then reflected back to the user and executed to gain access to their information.