Ygthkb

I recently discovered that my website had a page with a SQL Injection vulnerability. Upon testing, it was easily exploitable with a pentesting tool like sqlmap. How do I figure out if the site database has been accessed with a SQL Injection attack, possibly exploiting this loophole? The server is running Apache/2.4.18 and MySQL Ver 14.14 Distrib 5.7.16.

To be pro-active you may have your application to use PDO instead of plain SQL query.

Measures to detect SQL Injections could be :

1. Alert if any query running beyond X secs or any breaching value to relevant teams.




2. The team could see if slow query log / show processlist contains unusual entries, if confirmed as SQL injection kill the query and remove that application user as a preventive measure.

See Apache's access.log. Interesting things show up there.

Since you log all queries against the database, look for queries that don't belong.

Start with queries that failed. Assuming your app isn't riddle with bugs, there should be very few queries submitted to the DB that fail. Attackers typically have a set of queries they execute once they find a vulnerable app. If you apply the principle of least privileges on accounts used to access the DB, you should find a bunch of failed queries. There will also be queries that fail because a less sophisticated attacker might have a bunch of queries that are not compatible with your database edition, version or vendor.

Next, look for queries/commands that could not have been generated by your application. For instance, if the application should never accesses system tables, system functions, information schema, etc... but you see them in your log, that's a good indicator something might be amiss and warrants deeper investigation. Looking at your OS logs might be helpful here in case they tried or succeeded in planting a backdoor/rootkit.

Once you're done with that, look for queries with unusual/unexpected behavior. For instance, queries that return significantly more data than normal. If you see queries that access all tables around the same time or ran show tables then accessed each table in order, there's a good chance you have an attacker that tried (or succeeded) to exfiltrate data. Even something seemingly innocuous like SELECT * without a WHERE clause is suspicious (assuming your app doesn't do this). Note that this applies to any possible query, not just SELECT. The attacker might be some disgruntled employee and decided to randomly DELETE or UPDATE data to get you in trouble with your auditors or worse.

Looking at IP addresses is often not helpful even if you're looking at the web server logs unless you have a narrow and/or well known band of IP addresses your users connect from. Few attackers do it from their home PC anymore. Bots and proxies are found all over the world plus IPs are easily spoofed. Unless you get your ISP or Telco provider involved, it's unlikely you'll get very far looking at your own logs. One better indicator is your corporate firewall or network logs to find unusual outbound IP targets. An attacker that exfiltrates data has to send it to some real endpoint. That is usually to a place that isn't cooperative and/or moves slowly when foreign companies or law enforcement comes knocking.