amuck-landowner

SQL Injections and WAFs

Jonny_Evorack

New Member
Verified Provider
Hi Everyone,

This is a "Tips and Tricks" emails I sent to all of our customers. It's pretty basic but I thought I'd post it here incase anyone is interested :)

Cheers

Jonny
Evorack

This is a first in a series of monthly "Evorack Tips", that we hope to share a few things we've learned in hosting that may help you folks! White these tips will not provide exhaustive details of the topic in hand, we hope that they will spur your interest to investigate further. Furthermore, some topics may be too light for the more experienced users, but we hope to include some meaty topics soon! While I (Jonny) will be writing this first one, future ones may come from other members of the Evorack team, so stay tunned to hear what they have to say! We may eventually start a blog on this but we're very keen to hear your ideas! So without further ado, let's get started...

This month's topic: SQL Injections and WAFs

I thought that this topic was relevant due to the recent bugs discovered in WHMCS. As many of you will know, a lot of websites and Web Applications use a database backend, WHMCS (our billing system) being no excpetion. The database is "queried" (searched + modified) using a language called SQL. The backend of a piece of software will have many oppourtunaties to run SQL queries against the database in order to return the data that it needs (such as your customer details), as well save data into the database (like when you submit a ticket). Giving the web application SQL access to the database comes with great responsibility:

You only want data to be retrieved from the database, or the database modified in any way, only when you expect it to. 

An SQL injection attack occurs when a malicious user manages to manipulate your web application in such a way as to execute an SQL query that was never supposed to be executed, potentially exposing sensitive data and/or deleting/currupting information. This is of course very, very bad! This generally occurs when the malicious user insert some SQL syntax into a normal user field (e.g. username), and the web application doesn't "sanitise" (I'm from the UK - no Z's!) the input, leading to the rogue SQL syntax to be executed against the database. As such, the bottom line rule is that:

Your Web Application must check and double check (sanitise) all user input before dealing with it, to ensure that it is not executed against the database as an SQL query.  

If you are a software developer, you should definately read further into this, although it's also very important for server administrators as well. Software Development using database technologies should use "Prepared Statements" which generally speaking, escape any SQL syntax to "turn" it into normal text. That is probably the most basic thing you can do as a software developer. There is no need to reinvent the wheel and check all input manually (although there is no harm doing this as well), but always follow the best practise for the language you are using, and never let user-given data end up being part of an SQL query, with escaping first. Unfortunately like many bits of software out there, WHMCS is fixing areas of the code where they have no done this properly, by providing patches (which us Evorack staff quickly apply!).
 

There is another line of defense that a server administrator should use: A Web Application Firewall (WAF)


A WAF is basically a piece of software that sits in-front of your website and looks at user submitted data, trying to analyse traffic to make sure that a user isn't being malicious. It's similar to what your web application should do by itself anyway, but a WAF is used as a general line of defense, whereas the web application software will of course be specific to the app itself.

You can run a WAF directly on your Evorack VPS (using mod_security), or you can use a paid-for service such as CloudFlare, which can provide such functionality. While we aren't sponsored by CloudFlare, we have no shame in admitting that it's been very useful for us to protect our Evorack systems from malicious users trying to perform SQL Injection attacks (amonst others!). It has stopped malicious users from reaching our WHMCS installation, keeping these users a safe distance away from our systems, protecting user data and our database integrity. 

A WAF is definately not a "install-once leave it alone" solution! Quite the opposite: you have to constantly add new rules to it to allow it to detect new types of attacks that the script kiddies are using out there. Of course, if you use a paid-for service like CloudFlare, they will do this for you. It's also no substitue for failing to patch your software, or writing bad software to begin with.

Remember, like anything in life, good implementation starts with good design. I'm sure there's a saying somewhere out there that describes what I'm trying to say, but you get the picture :)

So there you have it: Our first security tip mailshot. We're still looking for a name for it. If anyone has any ideas, we're all ears!

I hope you've enjoyed this mailshot, and I hope you enjoy the future ones that we'll publish in due course. 
 
 

Kruno

New Member
Verified Provider
CloudFlare's WAF block legit requests - for example BitPay and WebMoney payments. Instead of fixing false positives, they just suggested to whitelist IPs. Yeah, I'm gonna whitelist 100s dynamic IPs daily... 

On the other side, Incapsula looks decent, I will test it somewhere this month. 

Atomic(ASL) modsecurity rules are great. They fix false positives within 24 hours and support is always fast to reply. I personally reported a few critical bypasses and they implemented it in a timely manner. Highly recommended!
 

splitice

Just a little bit crazy...
Verified Provider
If only people could learn to write secure code, its not hard either use an ORM (e.g Doctrine, Readbean etc) or atleast use PDO (correctly).

Almost makes me cry when I still see SQL injection in this day and age with all the tools at our disposal. ;*(
 
Top
amuck-landowner