Introduction to Second-Order Attacks

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 in the upcoming sections.

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.

Some web vulnerabilities are inherently second-order. For instance, consider a stored XSS in a social media network, where a user can send another user a message containing an XSS payload. When the other user opens the message, the XSS payload is triggered. As such, the injection point (i.e., sending the message) differs from the trigger (i.e., opening the message). In other words, the user-supplied payload is stored and displayed in a different endpoint unsafely, resulting in an XSS vulnerability. Thus, stored XSS can be considered a second-order vulnerability.

More specifically, any web vulnerability that requires this indirection can be considered a second-order vulnerability. These vulnerabilities are significantly harder to identify as the immediate injection point might seem secure, and a different endpoint must be hit to trigger the vulnerability. Thus, it is crucial to have a good understanding of the underlying inner workings of the particular web application to identify and exploit second-order vulnerabilities.

Recap: Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR) vulnerabilities are common web vulnerabilities that result from a direct reference to an object that users can control without additional authorization checks. This can lead to unauthorized access to the referenced object. As such, IDORs are access control vulnerabilities. For more details on IDOR vulnerabilities, check out the Web Attacks module.

Generally, the process of identifying and confirming IDORs consists of the identification of the direct object reference, the modification of the object reference, and the confirmation that unauthorized access takes place by reviewing the web server's response to the modified object reference.

Recap: Local File Inclusion (LFI)

Local File Inclusion (LFI) vulnerabilities arise when a web application includes files dynamically based on user input. If the user input is not properly sanitized, an attacker might be able to break out of the intended directory and read arbitrary files on the web server's local filesystem. For more details on LFIs, check out the File Inclusion module.

Recap: Command Injection

Command Injection can occur in web applications incorporating user-supplied data in system commands without proper sanitization. As many web developers know the dangers of command injection, exploitation typically requires bypassing implemented filters. For more details on command injections, check out the Command Injections module.