Introduction

Before discussing how to identify and exploit second-order vulnerabilities, let us first understand the critical differences between them and first-order vulnerabilities, what to look out for to spot second-order vulnerabilities, and then quickly recap the basic web vulnerabilities we will focus on.

---

What is a Second-Order Vulnerability?

When malicious user-supplied input does not trigger a vulnerability at the initial injection point but later, when the web application stores or processes it, this is known as a second-order vulnerability.

Example: Stored XSS

Consider a stored XSS in a social media network:

1. User sends another user a message containing an XSS payload

2. When the other user opens the message, the XSS payload triggers

Injection Point (sending message) ≠ Trigger Point (opening message)

The user-supplied payload is stored and displayed in a different endpoint unsafely, resulting in XSS. Thus, stored XSS can be considered a second-order vulnerability.

Key Characteristics

Aspect	First-Order	Second-Order
Trigger timing	Immediate	Delayed
Injection point	Same as trigger	Different from trigger
Detection difficulty	Easier	Significantly harder
Required knowledge	Basic app flow	Deep understanding of inner workings

Important: Second-order vulnerabilities are significantly harder to identify because the immediate injection point might seem secure, and a different endpoint must be hit to trigger the vulnerability.

---

Recap: Common Vulnerabilities

Insecure Direct Object References (IDOR)

IDOR vulnerabilities result from a direct reference to an object that users can control without additional authorization checks. This leads to unauthorized access to the referenced object (access control vulnerabilities).

Identification process:

1. Identify the direct object reference

2. Modify the object reference

3. Confirm unauthorized access by reviewing the response

For more details, see the Web Attacks module.

---

Local File Inclusion (LFI)

LFI vulnerabilities occur when a web application dynamically includes files based on user input. If input is not properly sanitized, an attacker may break out of the intended directory and access arbitrary files on the local file system.

For more details, see the File Inclusion module.

---

Command Injection

Command Injection occurs in web applications that incorporate user-supplied data in system commands without proper sanitization. Exploitation typically requires bypassing implemented filters.

For more details, see the Command Injections module.

---

Note on Second-Order SQL Injection

The Advanced SQL Injections module covers second-order SQL injections in detail.