Guard your WordPress security: Understand SQL injections

Guarding WordPress security - SQL Injections - Plesk

We all know that WordPress has historically been very vulnerable to hacks of all sorts. So most good web hosts will practice good WordPress security measures to avoid falling  victim to hacking. However, it can be hard to keep track of all the risks and develop a security solution that really protects your website.

Here, we’ll discuss how one of the most dangerous intrusions may occur. Code injections via SQL. Read on to discover what a SQL injection is, how it happens and what actions you can take to ensure your WordPress site isn’t a victim of an injection attack.

database-injection-icon

Understanding database injections

Hackers injecting code into a database isn’t uncommon. In fact, pushing rogue code into a WordPress SQL database is a frequently-used method for gaining unauthorised access to a site. It all comes down to WordPress’ reliance on SQL databases. And this has a big effect on WordPress security.

content-storage-icon

How WordPress stores content

Every WordPress site has a dedicated MySQL database – the standard DBMS used by WordPress websites. Whenever a page is requested, WordPress generates a SQL query. It consults the database for the content. Then plugs the database content into a page theme to render a user-friendly version of the content.

With the help of PHP SQL, queries are served to the system in order to make changes to the WordPress database. Including adding, deleting or changing the database itself. However, hackers do not necessarily connect with a database via WordPress or a control panel. In fact, code can be inserted into a WordPress database in a lot of different ways.

hacker-icon

What hackers do to inject code into a WordPress SQL database

Forms. Yes, hackers use your website forms to inject code into your WordPress SQL database. Whatever receives user input can be the gateway to a security issue in its worst form: an SQL injection. Anything like a contact form, login box, sign-up box or even the search bar

The problem with forms is that, in many instances, the submission is captured in the database. Add rogue code in the submission and the code is stored in the SQL database. So, all a hacker needs to do is to enter this rogue SQL code into a form instead of bona fide form responses.

One example is a form field that should only accept valid telephone details. Yes, you should restrict form responses to be in the format of XXX-XXX-XXXX. However, if you leave the field as free-form, a hacker could easily inject SQL code using that field.

So, what happens after an SQL hack?

There are two ways in which a hacker can insert code into your SQL database. The Classic method of doing so involves returning data to the web browser used by the hacker. It’s just the same way you use a form on a website, really.

A query like this can result in your database returning information inside the database. And the purpose of this WordPress security hack is to steal information that is sensitive, including SQL structure which can lead to further hacking attempts.

Another way of inserting code is using a blind SQL injection. Here the injection does not involve the return of data. But instead, the hacker will use the inserted code to run code on your database. This code could do all sorts of damage, including deleting all your database data.

wordpress-security-icon

Can’t WordPress security prevent SQL injections?

Yes, WordPress has gone to lengths to try and prevent these common SQL injection attacks. WP security involves validating and cleaning data which is submitted via forms.

For example, validation makes sure that data that is received on a form fit the criteria that are specified. Like matching the data entered into a phone number field against the nature of a real phone number. Another example is the way in which WordPress removes excess and restricted characters from input.

Nonetheless, there are some issues that current WordPress security tactics do not account for. Which means WordPress is not fully-secured against database injections that manipulate SQL code.

For example, in 2017, WordPress published a security update which fixed a known SQL exploit detected by the WordPress team. This protected the core of WordPress. The update, however, did not protect vulnerable themes and plugins. Overall, themes and plugins are vulnerable to exploitation whenever they use a form.

The developers behind these WordPress add-ins need to be very much on top of WordPress security practices. So that database injections don’t cause problems for web hosts. In essence, it’s best to take additional mitigating measures. Because fully managing what WordPress or add-in developers do is simply not possible.

Let’s take a look at what you can do to manage your WordPress security to avoid hacks due to SQL exploits.

prevent-sql-exploit-icon

Preventing SQL exploits

WordPress itself has a few tricks up its sleeve. But in the end, good sysadmins will add additional measures to make sure their WordPress sites do not suffer from an SQL attack. Here is a short list of practices you need to implement:

1. Trust is the key

There’s a whole lot of reasons why you should be really careful using plugins and themes. But SQL injection risk is one of the biggest. Only use of plugins and themes that come from reliable, qualified and trusted developers.

2. Update regularly

Remember that 2017 WordPress fix we mentioned earlier? It didn’t work for a lot of people. For the simple reason that these users had disabled automatic WordPress updates. So the update never rolled out to their WordPress instance.

When it comes to updates, you need to be really alert. Because it’s not just the WordPress core that needs frequent and regular updating. You also need to make sure your MySQL database software is updated.

Also, always keep your PHP on the latest version. Often, your website management console can make it easy to keep all these aspects of your site up to date.

It can be difficult to manage updates across multiple sites. But you can try something like WordPress Toolkit which can manage updates across a lot of sites via a dashboard interface. So it automates the update process. The golden ticket? You don’t need to log into hundreds of websites to manage updates for sites, plugins, and themes.

3. Control field entries and data submissions

We’ve explained how a SQL injection works. Want a simple WordPress security trick to thwart them? Control the types of data that can be submitted via a form field.

A name field should only allow alpha entries because there’s no reason for numeric characters to be there. Likewise, telephone or payment card data should not contain alphabet letters or special characters. Also, consider deploying sanitize_text_field() so that entries that are not correct or simply dangerous can be blocked.

4. Don’t use the default WordPress database name

This is a really simple WordPress security trick: change the standard WordPress database name. By default your WordPress database will have the prefix of “wp-“. Thus, making it easier for a hacker to use your databases’ credentials, especially with bots and automated scripts. Change this default name and you make it more difficult for them.

5. Keep track of who uses the database

Never give access to your MySQL credentials. And in the case where you just can’t avoid it, log the use of credentials and the overall SQL activity. If unsolicited changes are made, you can detect the problem quicker. WordPress security tools including WordPress Toolkit can help you do this.

6. Use a website application firewall

Yes, you can get a firewall for your website. A website application firewall or WAF can detect SQL injection attempts by analyzing form inputs on your behalf. WAFs will also block known-bad IPs from your site so they can never even make an attempt. There are plenty of WAFs on the market, check them out.

Finally stopping SQL injections in their tracks

Database injections are an incredibly common way to hack into a website, but luckily they’re preventable. Good WordPress security practices can make it difficult for even the most determined hacker to inject code into your database.

You have several tools that can help you, one of these is Plesk WordPress Edition which can assist you in your WordPress security efforts. It also provides a range of other WP tools which makes it much easier to manage and maintain WordPress applications.

Three New Web Application Threats and their Solutions

Web Application Threats

Malicious users will try to access your web application without your consent. Therefore, you should implement the necessary security features to protect yourself from new web application threats: Spoofing, information disclosure and data tampering. Let’s see how together we can mitigate threats using Plesk security tools.

1. Spoofing

Spoofing

Spoofing is one of the modern web application threats, despite security measures you may implement back-end to protect users’ credentials. It’s pretending to be someone or something other than yourself. And it can happen in many ways.

Fake User Authentication

Attackers can create a fake login page similar to that of a web application to trick users to log in. So that they can steal users’ login credentials. For spoofing, attackers can even use SET (social engineering tools) to clone a login page of a popular web application.

Fake User Authentication

Cross-Site Request Forgery (CSRF)

Cross-site request forgery tricks a web browser into executing an unwanted action. Like transferring funds from one account to another account in a web application where a user is already logged in. Attackers usually use social engineering tricks to implement CSRF by sending links to authenticated users on social media. In other words, those already logged into a web application.

Then unsuspecting users end up sending a forged request to a server on behalf of a malicious user. Though it’s quite difficult to prevent this, below is how you can mitigate cross-site request forgery.

How to Prevent Spoofing Threats

  • Implement an SSL/TLS Certificate

To defend against authentication spoofing, make sure that a web application such as banking portal has an SSL/TLS certificate in place. Plesk lets customers get these certificates for free in just a few clicks.

Spoofing Threat Prevention

Even less technical customers can use the Let’s encrypt extension on Plesk platform to easily create SSL certificates for their domains. And make it difficult for attackers to create spoofing attacks.

Generate Random Tokens  

Otherwise, to prevent forged requests, you can even use tokens to validate GET/POST requests from users. For example, to enable csrf protection in Flask-based applications, you can use the Flask extension CSRFProtect by enabling it globally.

from flask_wtf.csrf  import  CSRFProtect

csrf =  CSRFProtect(app)

Alternatively, you can use FlaskForm to prevent forgery request in flask web applications. However, the standard way of preventing CSRF threats in Java or PHP web applications is by implementing an anti-CSRF token only visible to the user’s browser and web application inside a session variable with a request. If the value of the session variable and hidden form field match, the user’s request is accepted.

2. Information Disclosure

Information Disclosure Threat

Allowing unauthenticated users to access documents restricted to only authenticated users can be defined as information disclosure. The following describe diverse ways information disclosure can take place.

IDOR – Indirect Object Reference

IDOR attack is possible when a web application provides direct access to the object based on a user-supplied input. It makes it possible for unauthorized users to access resources restricted to them. Let’s assume user A logs in to a banking web portal, then the user is redirected to the following url:

https://mybank.com/acc=00012345

In this case, 00012345 is user A’s account number. If the user wants to access other customers’ account details, user A just needs to change acc=00012345 to acc=000112367.

Therefore, the above action allows a user to access account details of another user without the owner’s consent.

How to prevent

There are different ways to prevent indirect object reference.  Another way to prevent exposure of real identifier to an internal object, like database record, is using a salted hash value to replace the identifier.

https://mybank.com/acc=00012345

https://mybank.com/acc=12eryrxhwgq

SQL Injection

SQL injection is one of the most common ways malicious users use to disclose information restricted from public view.  Attackers can send commands such as SELECT to download an entire database, CREATE to create new users in the database or UPDATE to modify accounts.

How to prevent

You can use prepared statements to prevent an attacker from changing the purpose of a query. A prepared statement separates the query from the data. Thus, the data submitted by an attacker can’t be used to modify the query. Moreover, for flask developers, you can also prevent SQL injection by using SQLAchelmy to interface with the database. It comes with features to prevent SQL injection threats.

3. Data Tampering

Data tampering is the act of intentionally modifying data through unauthorized channels. There can be two states of data: in transit and at rest. In both instances, malicious users can intercept and tamper with data. Here’s how data tampering can take place.

Parameter Pollution

Let’s assume a web application allows users to send sensitive data. Like login credentials or transact funds via GET and POST methods. In this case, an attacker can tamper with URL parameters and modify data.

To prevent parameter pollution threats in a web application, you need to encode user-supplied input whenever a user sends a GET/POST request to the backend server.

Session hijacking

Session hijacking

Session hijacking is also another type of attack where malicious users steal session cookies. Each user is assigned a session when they log into a web application. The sessionID is usually stored in a cookie. Attackers use session hijacking to modify data in transit from the client (web browser) to the web server.   

How to prevent: Generate Random Session IDs.

Moreover, Plesk also provides loads of security extensions for customers to prevent or mitigate threats not mentioned above. For example, the Sucuri Security Scanner extension on Plesk to remotely detect website security issues and weaknesses in the source code.

Sucuri Security Scanner on Plesk - Screenshot

Avoiding these new web application threats

Having said that, don’t just rely on Plesk extensions to protect web applications from web attacks. You also need to use your own secure coding practices to mitigate these threats. So, equip yourself, but stay vigilant.