From a high level, cross site scripting (short: XSS) can be described as the embedding of foreign code into a trusted context for execution. Technically speaking, XSS describes a client-side injection attack in which an attacker aims to execute malicious code in a web browser of the victim by including mostly malicious JavaScript in a legitimate web page or web application. The actual attack will occur when the victim visits the target web application that executes the malicious code. It is important to understand that the web application becomes merely a vehicle to deliver the malicious code for attacking the user – the targeted web application is not being attacked itself. Typically, an attacker would look for XSS vulnerabilities on web applications allowing comments, forums, message boards or any other component of a web application that allows user input to be embedded in the sites’ contents.

Usually when verifying XSS vulnerabilities, attackers tend to trigger alert boxes to demonstrate code execution within the browser. Such an alert box after a successful XSS attack might look like this:

This alert box has been spawned on a demo web application by accessing the following link:

https://x.x.x.x/search.php?keyword=cats<script>alert(‘XSS demo by e2 Security!’)</script> 

If this was a real web application vulnerable to an XSS attack, an attacker might now send the link above to a victim of choice, hoping for him to access the link. As the web application seems to embed the user input into its own context without any sanitization or encoding, a malicious JavaScript is likely to be executed in the victims’ browser.

What is the risk?
If a XSS vulnerability has been identified, an attacker will most likely try to insert JavaScript because of the vast amount of possibilities. By doing so, an attacker could then try to:

While the risk of falling victim to a cross-site scripting attack thus lies mainly with the users of web applications, an affected company could potentially suffer reputational damage and data protection problems if their web applications are vulnerable. However, if a XSS attack reaches users with elevated privileges within the target web application (e.g. administrator accounts) or even users with access to the internal corporate network, the damage dealt could be significantly higher.

How to remediate?
The organization OWASP provides guidance for various software and application security use cases. Within its’ series of cheatsheets, they mention some specially crafted rules to prevent XSS vulnerabilities at all. Please note that we will briefly mention a few of them here, while the full list can be accessed on the respective website [1]:

Though in some cases a web application firewall might support in protecting against XSS attacks, the rules presented by OWASP are considered more effective in the long run. These rules are meant to be applied at the level of a web servers’ configuration and the web applications’ source code.

Real life examples
Since XSS is comparably easy to identify, many vulnerabilities are reported every day. At this point we provide two current examples regarding XSS vulnerabilities, not just demonstrating how to spawn alert boxes, but showing the severity and complexity in the execution and remediation of these vulnerabilities:

[1]  https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

[2]  https://portswigger.net/daily-swig/csp-bypass-how-one-chrome-xss-bug-took-2-5-years-and-an-html-spec-change-to-fix

[3]  https://portswigger.net/daily-swig/pandora-monitoring-system-pwned-by-chained-vulnerability-exploit

Der Beitrag Cross Site Scripting erschien zuerst auf e2 Security.