We’re living in the Golden Age of data. Some companies analyze it to better themselves, others trade it for profit, none give it up freely due to its value — for their business, and for criminals, as well.

SQL (Structured Query Language) is an extremely popular way to communicate with databases. While many new databases use non-SQL syntax, most are still compatible with SQL. This makes SQL a handy tool for anyone who wants to access data, no matter their motives.

SQL Injection (or SQLi) attacks have been around for almost 2 decades. They never stop hitting Imperva’s Web Application Firewall (WAF). So we have a wealth of data and experience to share. In this post, we’ll share recent statistics and charts from thousands of sites under Imperva protection, as well as attack examples, and ways you can protect your website.

Common Attacks on SQL-Based Applications

SQL Injection is a code injection technique used to attack applications. Attackers can use tools, scripts and even browsers to insert SQL statements into application fields. The statements are then executed by the database engine. Such attacks are usually used to:

• Spoof identity
• Tamper with existing data
• Steal data
• Destroy data
• Change database permissions

The data behind an application is usually mission-critical, which is why SQL Injection attacks are considered very severe.

Statistics from Imperva WAF

Every day, Imperva’s WAF mitigates millions of SQL Injection attacks on the websites we protect. At least 80% of the websites we protect get attacked every month. Many hundreds of our sites face SQLi attacks on a daily basis.

Below you’ll find statistics on countries, industries and tools used in attacks we monitor.

Figure 1: Site industry distribution — It’s quite interesting that the most attacked industry is the health industry, but not surprising, since BakerHostetler’s 2018 Cybersecurity report stated that it was the industry with the most data breaches.

Not pictured are the most-attacked databases, which are (in decreasing order): Oracle, PostgreSQL, MySQL, and MongoDB. Meanwhile, the most-attacked platforms are WordPress, Drupal, Joomla, and Quest.

Figure 2: Country of attacked website vs origin of attack — it’s not surprising to see that hackers tend to attack websites within own country. Of course there’s a chance it’s quite the opposite —  these results might reflect hackers using VPNs/proxies that have an endpoint in the country they’re attacking, in order to evade geo-blocking.

There are many SQLi public exploits massively used on a daily basis. For example: CVE-2017-8917 and CVE-2015-7858 are both Joomla SQLi public vulnerabilities that were used in 66,000 incidents we monitored.

Figure 3: Top vulnerability scanners — due to the fact that we’re counting incidents, not requests, the number of payloads each scanner generates has no effect. Although SQLi Dumper takes the cake, the Joomla scanner is not far behind.

We monitor tens of thousands of attacking IPs monthly, and use attack analytics to find malicious IPs and protect against them. We gathered some interesting statistics by analyzing the attacking IPs during the last few months:

Figure 4: IPs that attempted an SQLi attack day after day. In blue: the percent of IPs that attempted an SQLi attack on the current and following day, out of the IPs that attempted a SQLi attack on the current day. In orange: the percent of requests containing an SQLi attempt sent by these attacking IPs, out of the total requests that contain an SQLi attempt.

It’s curious that even though, on average, less than a third of the IPs attack day after day (blue line), their requests constitute more than 80% of SQLi requests (orange line). This might be due to ongoing scans by various vulnerability scanners. These tools tend to bombard targets in search of vulnerabilities, which explains the high IP-to-Requests ratio.

Figure 5: Top attacking tools — being extremely generic and widely used as it is, it’s not surprising that cURL takes such a major slice. However, a drilldown revealed that most of the suspected requests sent with cURL are in fact post-attack checkups, i.e. hackers who got blocked and then used cURL to test if they can still access the website. cURL is followed tightly by Python — hacker’s weapon of choice, and Ruby — the language code used to write Metasploit.

Attack Examples

Here are some popular attacks we tracked in a recent month:

Table 1: Example of SQL Injection attacks

×

Jan 22 Upcoming Webinar

Unveiling the Cybersecurity Trends for 2025

Register Now

How to Protect your Application from SQL Injection

There are many ways to protect your application from SQL Injection attacks. Some should be used during application development, others should be used after the application is deployed.

Development Phase:

Use prepared statements – a way to “template” your SQL to make it resilient to SQL Injection. Only certain input values can be sent to the database, making it impossible to run a statement other than the templated ones. Values which are transmitted later using a different protocol are not compiled like the statement template. Therefore SQL injection cannot occur.

Here are two Python code examples, with and without a prepared statement. The code is based on a MySQL connector driver:

Above is a Python code example of a prepared statement. The values are sent to the “execute method” separate from the SQL text.

Above is a Python code sample without a prepared statement. The email may contain SQL Injection statements which can be executed by the database engine.

Other than prepared statements, here are other ways for preventing SQL Injection during development and deployment of an application:

• Sanitization — Get rid of any special character, word, or phrase that might be malicious. For example, removing the reserved words SELECT or CONTACT, or removing the phrase WAIT FOR DELAY or DROP TABLE. This isn’t the best practice, but it can be useful in some cases.
• Escaping — Escape characters that have a special meaning in SQL. For example, replace a double quote with two single quotes. This is a straightforward, though error-prone way.
• Escaping and pattern check — Number and Boolean parameter data types can be validated, while String parameters can be restricted to a pattern.
• Database permission limitations – Limit the applicative user’s permissions to only what is needed, as it may help reduce the attack’s effectiveness.

Post-Development – Application Security:

• Vulnerability Scanners – These can detect SQL Injection vulnerabilities in your application, which can later be fixed by the development team. Remember that applications change constantly – so you should run the scanner periodically.
• Web Application Firewall – WAFs can also detect and block attacks on your application.

Wrapping Up

It is essential to secure your product against SQL Injection, both to ensure it functions correctly and to prevent data leaks.
It’s a good practice to think about protecting against SQL Injection from the get-go, when you write code that accesses the database. This is the best time to prevent these vulnerabilities from ever happening, rather than patching them up later. The development process should include tests against SQL Injection, followed by external scanners.
Finally, a WAF is a great addition to your product’s protection. It will protect you against vulnerabilities you missed, while giving you time to patch them up the best you can.