WordPress SQL injection attacks: how to protect your site

Database injection or SQL injection (SQLi) attacks are among the most common security threats in the WordPress environment, ranking high in yearly WordPress security reports.

Since they’re so common and the vulnerabilities that make them possible are very widespread, understanding them and taking steps to prevent them can be overwhelming at first. This article will try to make the process easier by exploring:

• What SQL injections are and how they work.
• The various types of SQL injections.
• What hackers gain from SQL injections.
• Expert-backed solutions to SQL injections.

If that sounds good to you, let’s start.

What is a WordPress SQL injection attack?

SQL is a programming language used to manage relational databases. All WordPress sites use relational databases and relational database managers such as MySQL, MariaDB, and AuroraDB.

SQL injections are malicious uses of SQL to gain access to backend information meant to stay hidden from the public. WordPress SQL injections consist of hackers typing SQL commands in user input fields with the intention of breaking into websites. Common user input fields hackers use to inject SQL commands include login boxes, search boxes, or sign-up fields.

Because of the way SQL injections exploit vulnerabilities in user input fields, in some cases, they can be similar to cross-site scripting (XSS) attacks, another common cyber threat in the WordPress ecosystem.

How do WordPress SQL injections work?

Hackers perform SQL injection attacks by interfering with the queries an application (in this case, a WordPress website) makes to its database. A database query is a request for the information in the database.

One of the most common ways hackers inject malicious SQL commands is through input fields like username and password forms. An attacker can, for example, introduce a valid username for which they don’t have the password and then submit a SQL command in the Password field like this:

Instead of inputting the password, the hacker can input the following SQL command:

'OR username username_123 -- 

Note that after the -- there’s a whitespace essential for this command to work.

This command modifies the query to tell the database to allow this user to log in by either matching the username username_123 with its corresponding password (the traditional way of logging in) or simply by inputting the correct username and clicking Log in. This command makes the Password field irrelevant because the website will allow the user to log in simply by typing a valid username, regardless of what’s in the Password field.

This attack, however, wouldn’t work on websites that encrypt their passwords rather than passing them as plaintext. For those cases, a hacker may instead use only the Username field, inputting the following SQL command (with a whitespace in the end):

username_123’ -- 

The hacker would then type anything in the Password field since the SQL command in the Username field makes the password, once again, irrelevant.

These are two simple examples of the many methods hackers can use to break into websites by entering malicious SQL commands into vulnerable input fields. Knowledgeable website admins take security measures to prevent these attacks, but non-technical website owners may not be aware of this vulnerability, opening the door for further attacks.

Regardless of the method, SQL injections trick databases that don’t validate user input into giving hackers information meant to stay private.

Now that you understand how hackers can easily crack unsecured websites let’s explore the different types of SQL injection attacks.

Types of WordPress SQL injection attacks

In-band or classic SQL injections

In-band or classic SQL injections are SQL injection attacks that use the same channel to initiate the attack and extract the information they want. For example, a hacker can infiltrate a site using SQL commands on a browser. The results will be displayed on the same browser if they use an in-band SQL injection.

There are two common subtypes of in-band SQL injection.

Error-based SQL injections

In these in-band attacks, hackers input queries that produce an error on the database. For example, their SQL commands could contain deliberately incorrect syntax that causes an error response.

Based on the data they gather from the error messages, hackers can collect information about the database’s structure or devise ways to gain unauthorized access. With error-based SQL attacks, hackers can partially or completely enumerate a database (extract available data).

UNION-based SQL injections

In SQL, the SELECT statement selects data from a database, storing it in a result table called the “result set.” In the case of a WordPress database, the result set may include plugin-related data, comments, usernames, passwords, etc. The UNION statement combines the data from the result of two or more SELECT statements into a single result set.

UNION-based SQL attacks use the UNION statement to make queries that result in a combination of tables from the website’s database as an HTTP response. Hackers can use this method to extract valuable information.

Inferential or blind SQL injections

During in-band SQL attacks, hackers can send a query and receive a response on the same channel, like the browser they’re using.

In “blind” or inferential SQL attacks, hackers do not receive information directly from the database. Still, they can monitor the app’s response to the query they sent and gain information from it. This type of SQL attack also has two subtypes.

Boolean bling SQL injections

Hackers send a SQL query and observe the database’s response. The content of the HTTP response to the query varies depending on whether the query returned a Boolean true or false.

Even though the database didn’t explicitly return data to the hacker, they can infer whether the query (such as the length of a database entry) was true or false based on the contents of the HTTP response. By testing with multiple queries that pry for information about the database, hackers can slowly enumerate it.

Time-based blind SQL injections

With this method, hackers also want to know whether a query returned a Boolean true or false, but in this case they do it by measuring the time it takes for the response to arrive. To achieve this, they send a query that forces the database to wait a specific number of seconds to respond.

Depending on whether the HTTP response arrived immediately or with a delay of a few seconds, hackers can tell whether it was true or false. They can use this method to enumerate the database slowly.

Out-of-band SQL injections

These types of SQL injections are less common and used as an alternative to the previous types. Hackers typically use them when they can’t receive database responses on the same channel they’re using to attack it. Instead, they command an application to send data to a remote location, such as a server the hacker has access to.

Out-of-band SQL attacks only work when the hacker can access a server with commands that generate DNS and HTTP requests from other servers, a common feature in popular SQL servers such as Microsoft SQL Server and Oracle Database.

By making DNS and HTTP requests, hackers can transfer sensitive information from the victim’s database into their server.

What can hackers gain, steal, or accomplish with WordPress SQL injection attacks?

Hackers have various reasons to perform SQL injection attacks. The most common pieces of data they can gain access to include the following:

• Private information about the database’s structure.
• Sensitive corporate information such as intellectual property and trade secrets.
• Personally identifiable information (PII) about website users.
• Username and password lists.
• Confidential consumer details.
• Version and other information about the database management software.

If their SQL attack grants them direct admin access with stolen login credentials, hackers may be able to:

• Tamper with the database’s content
• Partially or entirely delete the database.
• Block access to the database’s data for other users.
• Make private information public.
• Void and manipulate monetary transactions.
• Manipulate financial balances.

These can potentially leave a lasting impact on the website and the brands behind it. For example, suppose the brand abides by personal information protection laws such as the European Union’s GDPR. In that case, they may face fines due to a security breach caused by SQL injections.

How to protect your WordPress sites from database injection attacks?

Experts consider SQL injection vulnerabilities severe because of their potential to disrupt a WordPress app. The fact that they’re also very widespread doesn’t make matters any better.

According to Wordfence’s 2022 WordPress security report, SQL injection vulnerabilities were the fourth most common category of disclosed vulnerabilities during the year. Additionally, Sucuri’s 2021 security report determined that popular plugins with hundreds of thousands or millions of installations, such as WooCommerce, All In One SEO, and WP Statistics, had SQL injection vulnerabilities that their respective developers eventually patched.

It can be hard to protect your site from SQL injection attacks because there are so many avenues for hackers to exploit, but experts have come up with various strategies.

Prepared statements

Prepared statements or parameterized queries are often considered the most effective way to avoid SQL attacks. The fundamental issue caused by injecting malicious SQL code into input fields is that they mix code and data, effectively tricking vulnerable databases into sharing confidential information.

Prepared statements ensure that SQL code is sent to the database server and parsed separately from data, making it harder or impossible for a hacker to inject malicious SQL code. They also make the database work more efficiently because they can be used repeatedly without recompiling.

It is the first and most effective measure database admins should take to prevent SQL injection attacks.

Stored procedures

Stored procedures are a sequence of instructions that can be stored in the database for later reuse. They’re often created to handle sequences of queries frequently applied to the database’s model, executing them whenever necessary.

Stored procedures can be as effective as prepared statements when they don’t include unsafe dynamic SQL generation. In this sense, they fulfill a similar role to the prepared statements, but the main difference is that prepared statements can’t be stored while stored procedures can.

Not all database management systems allow stored procedures, however, so their deployment depends on whether your system supports the feature. Popular management systems like Microsoft’s and Oracle’s support them.

Scan your website often

There are online SQL injection vulnerability tests you can run on your website (some of them are premium only). These tests will give you an overview of your current vulnerabilities along with more detailed descriptions of the risks your website runs and how to fix its security flaws.

Input validation or sanitization

Another measure that should be used in combination with prepared statements is input validation, which is writing code in a way that identifies malicious user inputs, the driving method behind SQL injections.

Experts consider the best approach to enforce input validation by applying “prefer listing” or “whitelisting” validation. With this approach, user input is strictly compared with a set of known, valid, and approved inputs. If the user input doesn’t conform to the whitelist of inputs, it’s rejected.

While whitelisting input validation is a best practice, it may still be vulnerable to workarounds and exploits, given the difficulty of mapping out all possible legal inputs. Also, poorly applied input validation may interfere with user experience by generating many false positives.

It’s best to combine it with prepared statements.

Escaping user input

“Escaping” user input means using a technique (generally adding a character before the user-provided string) to prevent user input from being interpreted as code instead of a text string. Remember that hackers input SQL commands into user input fields to circumvent security.

By escaping it, anything the user inputs is always forcibly turned into text and never interpreted as a SQL command. That should take care of SQL injections for good, but there are many ways for hackers to circumvent escaping techniques (which vary depending on the database management system), so they should never be the only option.

Ultimately, escaping user input is a form of blacklisting, the opposite of the recommended whitelisting techniques experts consider a best practice, so it shouldn’t be your only option.

Prevent WordPress SQL injection attacks to your site

There’s much more to explore about SQL injection attacks, but this article has introduced you to some basic points you should know.

SQL injections are a common vulnerability in WordPress websites and plugins, so protecting your site from them can be challenging. But if you know how they operate and follow our recommendations, your site will be much safer and protected from the most common forms of SQL injections.

If you found this post useful, read our blog for more WordPress insights, guides, and tips.