As a member of the BitNinja Development Team, one of our most important tasks is to develop the protection of BitNinja. When we deal with such a process we can see how an attack works or how a botnet can exploit a vulnerability. It's almost like watching these events behind the scenes.
That's why this blog series started—because there are some vulnerabilities we need to talk about.
The first patient is SQL injection.
My previous blog article which was about the Hackerone also encouraged me to make this blog series.
On this platform, there is a lot of public report for SQL injection.
For example in Drupal.
Previously we have already made an analysis of the SQL injection attacks, but now, let’s examine SQL injection from another perspective.
This attack vector allows attackers to use almost any query on a database in an unauthorized way. In most cases, the entry point is a wrongly-handled input or badly-used SQL queries on a website. The hackers can access passwords, accounts or other personal data by using this vulnerability.
To better understand it, I will illustrate an example of how dangerous this can be. In this example, there is a login page for a website. We can send a request with this URL: http://mypage.com/login?username=myusername&password=mypassword
And this PHP code handles the parameters of the request and performs the login:
The code is simple. If there is a row in the users' table where the username and the password match, then the user will be logged in and the parameters come from the URL. But what will happen if I put this value for the password parameter: ' OR 1=1 –- ?
In this the MySQL query will look like this:
With this, I could inject this part of MySQL code to the where statement: 1 is always equal to 1 and with the – expression I reached if the query has other parts then they will not be running because I commented them out.
Otherwise, I can log in to this website without knowing the password.
This is not the only one way to use MySQL injection. There are many options to exploit with this vulnerability. So we can run any subquery.
If you can, do not use PHP in a native way, use frameworks instead. In a good PHP framework, there is a possibility to write MySQL queries with a query builder instead of using raw queries.
But if you want to use native PHP then use prepared statements instead of concatenate or interpolate:
How can BitNinja protect against it?If you have multiple websites or you are a hosting provider with thousands of domains then I guess you don’t want to look at them one by one or to oblige your customers
. In similar situations, BitNinja can solve these problems. Our WAF 2.0 module protects you against SQL injections.
In the official OWASP Core Ruleset we have a ruleset for this attack vector. This is an very general ruleset so if you need to use it you must be very careful. I suggest if you enable it, use it in log-only mode.
In this case BitNinja creates the incident but it has no effect on your server. This is the best way if you want to filter out the false positive incidents. For example, you can disable the rules which cause false positives. In other cases, you have to know there are some web applications where the SQL injection is not a vulnerability, but it also belongs to the application. These are web-based database management systems like phpMyAdmin. In such situations, it is advisable to add these domains to a separate pattern where this ruleset is disabled. This process is a bit long but if you fine-tune the WAF 2.0 module for the SQL injection then you could enable the real-time defense.
We have customers who have already done this and BitNinja managed to stop a couple of interesting attacks:
Also, check out the previous and the next parts as well:
-Part 1: the introduction of HackerOne
-Part 3: HTTP Parameter Pollution (HPP)
-Part 4: Cross-Site Request Forgery (CSRF)
-Part 5: Remote Code Execution (RCE)
