CROSS SITE SCRIPTING
VULNERABILITIES IN WEBAPPS
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>
WHAT IS THE RISK?
- 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 :
- 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 
- Chaining multiple vulnerabilities (including XSS) to achieve a critical remote code execution