Prevent SQL injections on the old PHP website using software

Question

A friend of mine works for a company which owns a 15-ish years old website written in PHP using Apache/MySQL/home brew CMS and outdated hosting on OS Debian 8 "jessie". SSH allows passwords (with no fail2ban or similar) plus both their "admin" page and phpMyAdmin are exposed, accessible and they do not use rate-limiter or any other brute-force preventing techniques or software. Oh, yes, and website is vulnerable to SQL injections too. So, all together it is a security disaster. On the top of that, as I learned from Apache logs, they got some attention from malicious users and, obviously, it is just a matter of time when they gonna be hacked.

Due to the recent COVID-19 issues their company is trying to keep a business going and didn't layoff anyone, but they don't have a budget to re-write a website (yet). Their goal is to survive thru those tough times, mitigate as many issues as possible without touching PHP code and later re-write a website. That's why solutions from here, here or here are not gonna work for them.

So, he asked me about some temporary ideas/solutions which they can use next 6-9 months and I suggested to:

• Hide their admin page by renaming it from "admin.php" to a random name like "002cff74-84fd-4451-8014-a0d4ea669426.php"
• Move to a cloud VPS
  • it is cheaper than their current hosting
  • it has a newer OS with security patches
  • they can control SSH, phpMyAdmin and use fail2ban and/or other software if needed

---

However, SQL injections are still on the list and I'm not familiar with Apache/PHP to give more advices - I use both nginx/nodejs and IIS/.NET.

Here is my question: What would be the best way to temporary mitigate SQL injections without changing an application code?

Should I suggest to use .htaccess to filter queries? Should he use a proxy to do the same? Is there any other relatively inexpensive way to do that? Any help appreciated.

Answer 1

You will not be able to do much without one of the two:

• change code
• export the entire site in HTML

SQL Injection usually cannot be prevented on old code unless you rewrite it. Yes, there are WAF (Web Application Firewall) around, and they can mitigate the majority of the attacks, but if something escapes the WAF, the site is fully exposed.

Migrating to a cloud provider changes nothing on the security. An insecure home-hosted website is insecure if hosted on Amazon, on Google, on a darkweb provider. If the provider have some security plug-in, you may be a little less insecure. But vulnerable anyway.

If the site is a CMS, you can create a local mirror of the site in HTML (ask around for HTML Spiders), and host this one. There will be some missing functionality (search comes to mind), but it will be online, and invulnerable to SQL Injection. Other downside is that every time you change anything on the CMS side, you must re-mirror and re-export the files.

But I would recommend to edit the code. If you grep -R mysql_query /path/of/the/cms you can have an idea of how much you will have to change, and I believe it would be faster to change the code than to keep exporting the site all the time.

Answer 2

SSH allows passwords (with no fail2ban or similar)

Can you install fail2ban on the server (or CSF+LFD) ? You should ASAP. Or better yet do not expose SSH to the outside world. If you can restrict access to a few whitelisted IP addresses that would be tremendous progress.

plus both their "admin" page and phpMyAdmin are exposed, accessible and they do not use rate-limiter or any other brute-force preventing techniques or software.

Do they really need phpMyAdmin ? If they do, limit access a few whitelisted IP address using .htaccess. The company may have a static IP address already. Otherwise disable phpMyAdmin.

Other things you can do:

• as suggested above a WAF can mitigate attacks
• some cloud providers (Cloudflare ?) provide WAF protection, in that sense hosting elsewhere could bring some benefits but this is not the solution
• enforce strong passwords on critical services subject to brute-force attacks: SSH, Mysql
• try to pentest yourself: I suggest using Nikto. This tool might also find other vulnerabilities you do not even suspect. Then show the report to your friend. This should convince them about the urgency to fix things. If the situation is a bad as you describe, a script kiddie can hack the site in 10 minutes and you will prove it.
• renaming the admin page: not a long-term solution but better than nothing
• take down the site and put a placeholder page in the meanwhile ? Unless the site is 'vital' to the public you should seriously consider it. A placeholder page does not look good but a 15-year old website probably doesn't look good either.
• suggestion made by ThoriumBR: "export the entire site in HTML" => for this you could use wget or httrack from another machine then deposit the files through FTP, then get rid of the CMS and the database.

Quite obviously they have other priorities and the site is not getting fixed any time soon. The more you wait, the higher the likelihood of a breach. Do that pentest, and your friend will realize the risk is real.

Answer 3

Unless you can map out what might be legitimate queries in URLs a WAF will be a disaster (this should only allow you to mitigate the disaster, not prevent it, and will still require a lot of effort - expect to have to write a custom regex for each parameter in every URL).

You won't be able to run it on a modern PHP install without a MySQL shim (e.g.).

without touching PHP code

Clearly they are under the impression that writing code is all there is to publishing a custom application or at least the vast majority of the cost. Avoid at all costs. This is not going to end well.

If they are holding your first-born to ransom and all legitimate access is authenticated, then put the site behind a proper authentication page (i.e. running on a separate webserver with proxying configured for everything other than the login page) which sets a cookie containing an encrypted expiry time and any other things which might be useful in identifying the user (don't use IP address / ASN number probably safe / major version information from user-agent). Add an auto-prepend on the backend site which fires for every page, checks the cookie is valid / has not expired and bounce them to the login. Replace the backend login with something which accepts a curl call from the frontend login to setup and return a session id.

This won't stop someone with an account from hacking the site but will reduce the attack surface.

(BTW the three "solutions" you cited are the same solution stated in 3 different ways).