0

Without going into the platform underneath, is there any effective way to protect a web server from SQL injection? Any special Apache module or config? Would fail2ban be appropriate here?

  • 1
    Apache isn't an SQL server, but by the time the SQL gets to any server it has already potentially been injection-attacked. You're asking the wrong question about the wrong component at the wrong side of the system. – user207421 Oct 25 at 6:43
31

Apache is not subject to an SQL injection, as it is not a database.

If you want to protect an application Apache runs which in turn calls a database, you could put a WAF (Web Application Firewall) in front if it.

Another approach would be to use mod_security in Apache with a ruleset that looks for SQL in the post/gets.

Fail2ban would be of very limited use as it scans log files for signs of brute force attempts. An SQL injection would often not be visible in the logs, and even if the logs are extended so as to expose this information, they are unlikely to be of much use, as they will pick up the request after its been processed.

  • I'm looking into modsecurity ( modsecurity.org ). I've never used it before. It looks interesting. Thanks! – RedNano Oct 23 at 9:04
  • 9
    "Another approach would be to use mod_security in Apache with a ruleset that looks for SQL in the post/gets." Sorry, but that's a terrible idea. In all seriousness, there's no way to have that sort of protection in the general case without either being completely ineffective, or being horribly susceptible to false positives. – Joseph Sible Oct 24 at 2:12
  • @JosephSible That article is from 2006 and does not mention mod_security. Yes, its impossible to fully prevent SQL injection in arbitrary code, but its like saying dont run AV scanners because they wont detect all new Virii. Perfect is the Enemy of good. I understand the SQL injection rules for mod_security are quite well established, so obviously they have some beneficial effect. Also, if you have known SQL injection vectors on servers you cant update (it happens, even though it shouldnt), this can help. – davidgo Oct 24 at 3:48
  • 1
    @davidgo If virus scanners had as high of a false positive rate as that sort of SQL injection "protection" does, we absolutely wouldn't run them either. The reason that virus scanners are acceptable is that they stop a reasonable number of viruses and have few false positives. – Joseph Sible Oct 24 at 13:40
  • 2
    @josephsible - Shall we agree that the correct place to fix SQL injection is in the app, and anything else is less then ideal - but if yodefinately u can't control the app and can't substitute it, limiting SQL using mod_security or equivalent appliance is better then nothing (but not great) – davidgo Oct 24 at 18:02
18

SQL injection is well documented. Fix your applications, not necessarily your web server.

CWE-89 categorizes SQL injection in detail. Note how mitigations like parameterization or using a decent persistence library are in the development phase. There's only so much a WAF style filter can do post deployment.

OWASP has practical resources for how to develop applications correctly avoiding SQL injection in the first place.

MITRE ATT&ACK categorizes it as a public-facing app exploit and lists software updates and application isolation among mitigations.

  • 3
    Also think that this is far more of an application problem than it would be a server problem. – Martin Zeitler Oct 23 at 23:57
4

SQL injection should be prevented at the application (using parameterized queries, escaping user input, using stored procedures, etc). Other ways of mitigating against SQL injection would be things like Apache's mod_security or using a service like Cloudflare.

  • I'm the system administration, not the programmer of the ap. Sometimes, (most of the times) this approach is out of our reach and we have to implement as many security features as possible because even if there's anything with this objective already implemented in the app code, it could be flawed as well. – RedNano Oct 27 at 8:19
2

As written previously, you should tackle SQL injections on an application level. If you use out-of-the-box software like wordpress, keep it up to date. If you develop yourself, use prepared statements whenever possible and never ever trust user input.

If you really want to do some hardening, use .htaccess to forbid any URLs that contain a semicolon or two dashes. ( ; and -- ), That will catch... well, maybe 1/3 of the attacks? Don't rely on that though.

That said, you can and should harden your server as much as you can, just keep in mind that some restrictions might affect legit traffic as well. Assuming you use PHP, check Suhosin.

2

In the olden days we used to sanitise inputs in the application, before they got near the database. Maybe things are 'different' these days. Here's a post from 11 years ago, which has been active recently: https://stackoverflow.com/questions/129677/how-can-i-sanitize-user-input-with-php

  • it still happens at application level. It's just these days often handled transparently by web application frameworks rather than the application developer having to hand code it all. – jwenting Oct 25 at 3:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.