Thanks to central log monitoring, we keep a detailed track of all traffic that goes to our customers’ websites for LowCost, NoLimit, WebSite and WMS services. We can find those under attack very quickly and hide them behind WEDOS Global Protection (if they use our DNS). Most of them are L7 attacks with a large number of requests (someone is simply calling your site with tens to hundreds of thousands of requests per minute). However, the number of SQLi attacks has been increasing in recent days.
SQLi attacks
SQL (Structured Query Language) is used to communicate with the database server. You have data such as articles, comments, registered user information stored in the database and you can pull specific data using SQL.
If the script needs to retrieve some data based on what it receives from the visitor (name, password, search query, comment, etc.), then it must insert the visitor’s input into an SQL query.
Simply put, if the user is, for example, a Ládík, who wants to know what credit he has, he asks the database server script via SQL what credit the user named Ládík has.
SQLi (SQL injection) attack is based on the fact that the attacker assumes (guesses) what the SQL query looks like and tries to modify the input to get the desired result.
For example, if the “who is currently logged in” is stored in a cookie, an attacker could try to modify the cookie value (change his name for Ladik or other users) and find out how much credit each user has.
To prevent this from happening, the programmer must treat all inputs he receives not only from the user. It is possible to insert a malicious piece of SQL into the browser name. You can see a sample of such an attack from January 2022 below (the malicious code is sent in the useragent header). The information where the user is coming from was also fraudulent.
Increase in the number of SQLi attacks
We encounter SQL attacks every day. Most of the time, however, the attacker tries not to attract attention. Often it goes after a specific vulnerability (untreated input). It performs a few queries per hour from different IP addresses, so unless you are specifically looking for this kind of attack, it is easily lost in the statistics. It does not usually cause server overload, sometimes it ends up with 404 or 403 error (if the programmer has prepared for this situation). Sometimes you see it as a 500 error, which is already glaring and mostly wrong.
However, this low-key approach changed at the end of July. At first glance, it looked like an L7 flood attack. Thus, an attempt to overload the number of queries.
Sometimes customer scripts were not ready for this and then it led to web hosting resource exhaustion and 503 errors. However, after we increased the number of PHP threads to 25 for all NoLimit at the beginning of the year, the web hosts really last a lot 🙂
The following chart shows the TOP 10 targeted sites by domain, and how they handled the attacks. The graph is for 7 days and it only shows a specific sample of SQLi attacks, so it’s not all of them.
There is really a big difference between a site where the programmer has treated this kind of attack and throws away the invalid inputs (terminates the script) and where the script continues to run.
This particular kind of SQLi attack is like a brute force attack. An attacker tests different variants in quick succession, so this can end up exhausting server resources. Just throwing it away and exiting the script with a 403 error is the best you can do.
The following chart shows the TOP 10 attacking IP addresses. The graph is for 7 days and it only shows a specific sample of SQLi attacks, so it’s not all of them. Interestingly, some IPs try to generate random browsers and others make do with a sample of a few real ones.
As far as “damage” is concerned, a few IP addresses hit sites that had no protection against this kind of attack (they didn’t discard nonsensical inputs) and tried to process them. When they bought it, even 25 PHP threads were not enough and led to 503 errors. However, it didn’t run for long. We have automatic filters against L7 flood attacks that put conspicuous attacking IP addresses on temporary blacklists. Moreover, as soon as the monitoring warnings start coming in, the technicians put the attacking IP addresses on a permanent blacklist, which starts blocking the IP address everywhere within a minute.
How can I defend myself against SQLi
If you don’t get tens of thousands of these attacks per minute, our NoLimit web hosting can help you prevent them by putting a rule in .htacess that blocks specific strings in the URL.
If you look at the log of one of the attacks, you’ll see that it repeats classic SQLi characters.
From these attacks, we selected the TOP 100 most used attacks and then found that if you blocked queries to pages with SELECT%20 and SELECT%2F in .htaccess, you would block 99.89% of all attacks. That’s pretty decent for a one-rule.
Of course, if you have a page that contains SELECT (space) or SELECT/, it will not work for visitors. However, these are not commonly used in URLs (the space is replaced by a – or _ character, and / can cause problems because / is used for the directory structure).
You might be thinking, why not block attacking IP addresses instead? Unfortunately, attacks come from two sources. One is apparently compromised VPSs in Microsoft datacenters and the other is coming through a large VPN provider that boasts that it has up to 300,000 IP addresses. When you put that many in .htaccess, it slows down the loading of all your pages significantly. Plus, if someone is using that VPN, they can’t get to you.
WEDOS Global Protection
It’s most convenient if you leave everything to us. Respectively to WEDOS Global Protection. First of all, you don’t have to keep track of current events, invent rules for .htaccess, where one typo means 500 errors for the whole site, and most importantly, you don’t block potential visitors coming through the VPN.
We’re gonna make it simple. We put a page in the path of suspicious traffic that tests whether it is a robot or a real visitor. Either via Captcha, or just a simple javascript redirect conditional on saving and reading the cookie.
In the future we would also like to put all VPN and proxy servers in one group and offer directly to the customer how he wants to deal with them on his site (do not check, redirect, captcha, block).
Conclusion
WEDOS Global Protection can be used by anyone. You do not need to have hosting with us. The version for personal use will be free, if you want to create your own rules or you are a company it will be only a few hundred crowns per month. Coming soon 🙂