OWASP Top 10 in 2017: Cross-Site Scripting (XSS) Security Vulnerability Practical Overview
Cross-site scripting (XSS) is #7 in the current OWASP Top Ten Most Critical Web Application Security Risks – and the second most prevalent web application vulnerability. It is thought to exist in two-thirds of all applications.
Monday, April 5, 2021
HackerOne's 2018 report says that the Cross-Site Scripting (XSS) continues to be the most common vulnerability across all industries that run a bug bounty program, apart from healthcare and technology. In the meanwhile, a non-profit Open Bug Bounty project helped fixing over 125,000 XSS on various websites across the world. Google, for example, continues paying up to $7,500 for an XSS flaw that permits taking over a user account.
Want to have an in-depth understanding of all modern aspects of
Cross-Site Scripting (XSS) Security Vulnerability Practical Overview?
Read carefully this article and bookmark it to get back later, we regularly update this page.
According to Veracode’s latest State of Software Security report, 28% of all applications have a SQL injection flaw when the application security company first scans them. And, as high as, 40% of applications have an XSS flaw.
According to Veracode, 28% of all applications have a SQL injection flaw at first scan. And, as high as, 40% of applications have an XSS flaw.
In 2014, a security researcher discovered and revealed vulnerabilities in auction website eBay.com. Exploiting flaws in the website's code, attackers would be able to redirect users to fake login pages, stealing their authentication credentials. The flaw in question is known as XSS – Cross-Site Scripting [CWE-79] – a security flaw which allows for unauthorised scripts to be inserted into web applications. These vulnerabilities were supposedly patched; but in 2017 new reports surfaced of similar attacks. Despite eBay's efforts, XSS vulnerabilities are a persistent problem, for them and many other sites and web-apps. OWASP cites XSS as the second most prevalent security risk, putting it at #7 in the top 10 ranking of application security threats.
Cross-Site Scripting
OWASP outlines three different forms of XSS vulnerabilities that can affect applications: Reflected XSS, Stored XSS and DOM XSS.
Reflected XSS, also known as Non-Persistent XSS, is the most commonly-seen XSS attack. If attackers find a vulnerable application, they can insert their own code or scripting, which will execute for the end-user. Typically, this could be performed by a specially crafted URL that includes the malicious code at the end:
The attacker then needs to find a way to get users to activate the malicious code, usually through phishing-style attacks that trick victims into clicking the link. The malicious code in the link interacts with the vulnerable application and is reflected back to the browser where it could, for example, steal the victim’s session cookies.
Stored XSS is also called Persistent XSS. This is a less common attack vector than Reflected XSS, but potentially more damaging. Stored XSS vulnerabilities occur when an application allows malicious code to become a permanent, or at least a long-term part of the user-accessible content. An example would be where a website allows HTML formatted user comments. An attacker could post a message containing specially crafted JavaScript capable of stealing the next visitors’ session cookies – and compromising their accounts.
DOM XSS, or Type-0 XSS is an attack against client-side rather than server-side code. Here the malicious code does not touch the web server, but is reflected by the JavaScript code entirely on the client side.
This form of XSS vulnerability is seen less often than the other types, but is potentially the biggest threat of the three. Since the effect is seen client-side, DOM XSS is more difficult to detect and prevent.
The three different types of XSS are united by a common aspect. They all allow users to be exposed to code not intended by the web-app developer. However, the methods attackers use for injecting it into the app and delivering it to the end user differ widely for each XSS type. This presents a three-pronged challenge for developers, as protection against one type of XSS will not necessarily mean the app is protected against the other types.
The scope for Cross-Site Scripting
The potential for damage stemming from XSS vulnerabilities has been known for more than a decade. As early as 2005, the Myspace social networking site was subject to the infamous XSS-based Samy worm. While relatively harmless and non-malicious, the worm exploited an XSS vulnerability to execute scripts in other users' browsers, including self-replication. The worm spread to over one million users within hours, before Myspace took the website down to combat it.
Despite such early warnings of the dangers of XSS, the problem remains common. In 2017, Google researcher Tavis Ormandy discovered a DOM XSS vulnerability in a Chrome extension that was automatically installed during an Adobe security update. The extension had something like 30 million installs, but contained an XSS vulnerability that allowed privileged JavaScript execution. Ormandy described it as having ‘critical severity’.
High-Tech Bridge CEO Ilia Kolochenko comments on the seeming intractability of XSS vulnerabilities over the years: “This can probably be explained by high customisation of web applications. Almost every start-up creates its website and web-based applications from scratch or uses some customization. At the same time, they try to save money and consequently hire unexperienced developers. A toxic cocktail of new code and unaware or careless developers unavoidably leads to numerous vulnerabilities. In larger companies, problems are similar – because of tough competition they have to innovate and release new products and applications very frequently. At the end of the day, they simply have no time or budget for security.”
XSS vulnerabilities are easily discovered by attackers. Respectively, they must also be easily discoverable by defenders.
The danger of XSS vulnerabilities is that they are easily discovered by attackers. The irony is if they are easily discoverable by attackers, they must also be easily discoverable by defenders. And indeed, there are automated tools that will help defenders find and eliminate XSS vulnerabilities in their code.
Since attackers can use these tools, it is important for developers to use them as well.
Solutions
Implementing a strong Content Security Policy, or CSP, should be the first step to protect against XSS. CSP is a security standard which originated specifically to counteract XSS threats. CSP is included in the HTTP header, and provides instructions for compatible browsers on which domains and commands to trust. However, developers should be aware that CSP, while good protection against server-side XSS, does not affect the client-side DOM-based XSS vulnerabilities.
Implementing a strong Content Security Policy, or CSP, should be the first step to protect against XSS.
More specific steps to protect against XSS risks will depend a great deal on the needs of the app and the framework being used. Proper data escaping in an application will help to strip out any badly-formed or unexpected code on delivery to the client. Context-sensitive encoding should be employed client-side to ensure that any rogue code is handled safely by whichever output method is being used. OWASP has provided several guides and cheat sheets for XSS prevention, testing and patching.
Web developers need to have intimate understanding of the limitations of their programming framework. JavaScript, for example, is the language which most XSS attacks involve, and requires careful construction to eliminate XSS risks. Other frameworks include XSS protection by design, like Ruby On Rails and React JS, which has data escaping enabled by default.
The good news for app developers is that the high detectability of XSS from automated tools doesn't just benefit attackers. High-Tech Bridge's ImmuniWeb service combines the scalability of automated vulnerability scanning with manual testing assisted by machine-learning and artificial intelligence for thorough and accurate application security testing. Don't forget to also test your general server hardening and CSP with ImmuniWeb's free WebScan tool.
Latest news and insights on AI and Machine Learning for application security testing, web, mobile and IoT security vulnerabilities, and application penetration testing. 
