CROSS SITE SCRIPTING

VULNERABILITIES IN WEBAPPS
PART II

 

GENERAL DESCRIPTION

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: 

    • steal session information to access the web application himself 
    • trigger actions within the same or a different web application on behalf of the user – also known as Cross Site Request Forgery (short: CSRF) 
    • exfiltrate accessible information (e.g. personal data of the attacked user, keystrokes (via Keylogger) etc.) 
    • directly attack the users’ system by exploiting potentially existing vulnerabilities in the used web browser 

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]: 

    • Rule #0: Never insert untrusted data except in allowed locations 
    • Rule #1: HTML encode before inserting untrusted data into HTML element content 
    • Rule #2: Attribute encode before inserting untrusted data into HTML common attributes 
    • Rule #6: Sanitize HTML markup with a library designed for the job 
    • Bonus Rule #1: Use HTTPOnly cookie flag 
    • Bonus Rule #2: Implement Content Security Policy 

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: 

    • How one XSS bug in Google Chrome took 2.5 years to fix [2] 
    • Chaining multiple vulnerabilities (including XSS) to achieve a critical remote code execution [3] 

 

[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 

 

Share on facebook
Share on linkedin
Share on twitter
Share on telegram
Share on xing
Share on email
Share on facebook
Share on linkedin
Share on twitter
Share on telegram
Share on xing
Share on email
Cyber & Information Security
HTTP