If you started gaming in the early days of Sega, you’d probably be familiar with the The 1991 phrase: ‘All your base are belong to us’, from the game ‘Zero Wing’.

The phrase became a meme very quickly, especially because of how funny the bad translation was, and yet how it was appropriate. Over the decades, the phrase turned out to become something people used in the context of “All your ____ are belonged to us”. In case of malware attacks, it fits to imagine that hackers attacking your website’s database keep chanting “All your (data)base are belong to us”.

Of all the vulnerabilities that allow for database exploits, Injection attacks are the most rampant. In fact, they’ve been on OWASP’s list of top 10 most prevalent exploits on websites to date, and for good reason. You might think that getting to access a website’s database is a complicated process… but it’s not.

Whenever your website’s visitors and users type out comments, or click on buttons on your site, they’re inputting data. If your website doesn’t make sure that users’ inputs follow a specific format, it could get tricked into running bad SQL commands or queries that are input via user-entry fields (like in a comment section). This is why SQL Injection is one of the most common attacks, especially on WordPress websites.

The problem with these vulnerabilities, is that you can’t control users’ inputs on websites. You can only filter them in, or out.

Here are a couple of general examples to show how SQL injection works:

Say you have a form on your WordPress website that allows users to submit their phone numbers. Usually, forms accepting phone numbers have certain criteria for the inputs: at the very least, the length of the phone number is fixed and special characters aren’t allowed.
The problem arises if user inputs are accepted indiscriminately, no matter the format. In the above example, if a hacker inputs malicious code instead of a phone number, and your website isn’t designed to verify the content entered, then your site is in trouble. And if this malicious code consisted of executable SQL queries (like a line of code asking for the admin’s credentials), it would access the website’s database for the data the hacker wanted (in this case, admin credentials to your site), and get it back to them.

Here is another example:

The golden rule, in web security, is this: expect data that comes from anywhere from outside the system, to be malicious.

The silver rule, is to try and have control over any such data.

One way to filter data in, would be via a whitelist: a compilation of every combination of data you know users will input, and can be trusted, like letters, numbers, and strings. Validating users’ inputs, based on how well they comply with your whitelist, is one way to prevent SQL injection. However, whitelisting isn’t fool-proof, and there are still a number of ways through which SQL code could get to your website.

What’s interesting is that WordPress’ core hasn’t had any such issues in the recent past. This is because it validates all inputs before passing them to your WordPress database. This means WordPress checks if users’ inputs stick to the format they are supposed to (i.e. comments don’t contain <script> tags). WordPress also provides a set of API’s which sanitizes the input ensuring that SQL Injection attacks are just not possible. Sanitization makes sure that the data entered only contains safe characters (like alphanumeric characters in a contact form, no special characters). Such vulnerabilities are often seen in plugins/themes though; because while many plugins/themes do use above APIs or validate inputs, there are a few that don’t.

Real-world examples just show how scary this attack can be: Recently, Booking Calendar, a WordPress plugin used for making online reservations based on availability, exhibited an SQL vulnerability. The vulnerability allowed an attacker to enter SQL queries. Since this code got executed on the website’s database, it let the attacker view data from the database. Fortunately, the vulnerability was revealed to the developers of the plugin before anyone else, and they fixed it in an update.

(Note: If you’ve got this plugin installed in a theme, or it’s on your website as a standalone plugin, we ask that you update it immediately.)

There is no foolproof way to secure WordPress websites. In fact, even security plugins for WordPress sites are affected by these vulnerabilities. In 2014, for example, the All In One WP Security plugin demonstrated TWO vulnerabilities that allowed for SQL injection.
This is one of the reasons attacks on websites wreaks so much havoc: one vulnerability could give a toehold for one exploit, which could then be linked to another… And the cumulative damage to your site, is exponential.

This is why we came up with a website hack-scanner, that scans your site completely, gives you no false positives, and cleans out hacks with a single click (no technical assistance required!). Try it out for free, today!