Introduction

Cross-Site Scripting (XSS) has maintained its position in the OWASP Top 10 for over a decade, not because it's difficult to prevent, but because it's deceptively easy to implement incorrectly. I recently played Google's XSS Game (xss-game.appspot.com) — a deliberately vulnerable web application designed to teach developers and security researchers how XSS attacks work in practice.

In this write-up, I'll walk through my analysis and demonstrate how subtle implementation flaws can lead to security vulnerabilities.

The Vulnerability

The application attempts to protect against XSS by encoding special characters, but fails to account for different execution contexts.

Initial Analysis

To test if the parameter is vulnerable to injection, we attempt to use common special characters, and based on the response, we can determine the type of vulnerability the parameter is potentially susceptible to.

The first tested with special characters:

Input: 1337<>'"{}

The response revealed HTML entity encoding:

Your timer will execute in 1337<>'"{} seconds.
None
Input Reflected

Based on the response, the application reflects back all special characters we input, but they are encoded using HTML entity encoding.

However, noticed that one character was not handled properly, which is '. Based on the response, the application returns ' instate of &#x27;. The ' character terminated the string literal in the JavaScript context, allowing code injection despite HTML entity encoding elsewhere in the page. This may caused the application to be vulnerable to the Cross-Site Scripting (XSS) attack.

Exploitation.

To test our theory, we can craft a Cross-Site Scripting (XSS) payload that:

  1. Closes the existing string with '
  2. Inserts a JavaScript expression using the - operator
  3. Uses another ' to maintain valid syntax
Final Payload: 1337'-alert(document.domain)-'

Successful Execution.

None
Payload Executed
None
Payload Executed

Remediation & Recommendations

To prevent these vulnerabilities, developers should implement the following secure coding practices:

  1. Input Validation: Treat all user input as untrusted. Validate against a strict allowlist.
  2. Output Encoding: Implement HTML entity encoding on output. Ensure encoding is context-aware.
  3. Content Security Policy (CSP): Implement CSP headers to restrict the sources from which scripts can be loaded.
Content-Security-Policy: default-src 'self'; script-src 'self'
  1. Secure Libraries: Use modern frameworks that automatically handle escaping.

Reference: