WAF SQL Injection

What is WAF SQL injection?

A SQL match condition specifies the web request portion that you want to verify WAF, such as the Address or the query string. Eventually, if an ACL is created, you will specify whether requests contain the malicious SQL code you want to allow or block.

What is SQL injection?

SQL is a method for inserting SQL queries into the input fields through the SQL database underlying the system. These defects can then be misused if forms enable users to query the database using SQL statements directly.
For example, use a user and e-mail field and a password field for a typical login form. When the login info has been provided, it is combined on your web server with a SQL query. PHP is used to write the command.

What is a Web Application Firewall (WAF)?

A WAF is a defence layer 7 (OSI model) protocol that cannot withstand all kinds of blasts. The blast mitigation technique is usually included in an array of equipment working together to offer a wide range of strike vectors.
The WAF helps in filtering and tracking HTTP Web to Web traffic to protect web applications.

WAF protects online applications such as

SQL Injection
Cross-site falsification
Folder inclusion
Cross-site editing (XSS)

A WAF acts as a barrier on the front end of a web application between the website and the Internet access. A proxy server is a browser that secures a client machine’s identity; use WAF before reaching the server, it protects the client from exposure. A WAF is governed by a set of rules, which are commonly referred to as policies. These policies target to protect the application from malicious attacks.

Can WAF detect SQL injection?

Web Firewalls Application (WAF) usually produces millions of SQL Injection events every day. As security workers, we are concerned about the success of these attacks but struggle to scrub such high volumes of work (see Figure 1) that are highly prevalent with false positives. Here are a few ways to derive your value from your SQL Injection events successfully.
Most WAFs use the Mod Security Core Ruleset to generate events. A six-digit number identifies these rules to make identification simpler. Many rules identify various behaviors indicating a SQL injection attack, including any rule that starts with “942” and “981”.
Therefore, the action you can take is to block all SQL injections attacks identified by those numbers. However, there is a risk in this approach as many of the rules generate vast false positives. You face the risk of discouraging organic web traffic and, as a result, losing sales and revenue.

Many organisations set a rule to monitor and alert on these events rather than blocking them.

The reason for this is to avoid the false alarm impact and the fact that the vast majority of SQL injection attacks fail as they are. The challenge is to find those that are successful or have the best chance of success.

One strategy is to only alert on rules with a slight risk of false alarms. That can be hard to determine, but we, as WAF experts and researchers, have been trying to differentiate here. Any rule that has been identified as a frequent false alarm should be excluded.
Alternatively, keep generating SQL injection alerts but reduce their importance. They will only be examined if they match other alerts in your system.

One simple example would be a condition where an IP address listed on a high-value blacklist or threat intelligence feed conducts a SQL injection attack on your website.
This would combine a reputation alert and a SQL injection alert, increasing the importance of the overall correlated alert.
Even with these strategies, your SOC may receive too many alerts or too many false alarms.
We suggest you review your logs and events for ways to reduce noise. It may simply apply the above strategies and stay diligent in refining your alert rules until they are correctly tuned. Regardless, you can make your SQL injection events useful to your security monitoring and understanding of what is happening to your web applications