We are back with the second tech installment written by our colleague Andrei. Scroll down to find out interesting things about database security. His ideas will help you with both application level and server security.
APPLICATION LEVEL
In the first part of this series I mentioned that the focus should be on the users. Well, everything user related is stored in the database. The main concerns are:
- authenticating users
- controlling information that users can handle (CRUD)
Let’s go through these really quick.
Authentication basics
Nobody except the user should know the password, not even the database! But wait… how can we verify the password if we don’t know it? Imagine we have a function that can always generate the same hash from a string, but not vice versa:
secretPassword => bigHashX7fC
bigHashX7fC => ???
The database will store only the hash. When the user logs in and sends the password, the same hash should be generated, assuming the password is correct. So we can know the password is correct without knowing the password.
A supercomputer can generate a huge number of all the possible passwords. It can also apply one or more commonly used hash algorithms on them and store the results in something called a hash table. That way you can find passwords by their hash.
You may be thinking: who have I upset that bad, that will buy supercomputers and harness such power against me? Check out “crackstation.net”. I sometimes use it when I forget the password for the admin account on staging.
A brute force attack happens when someone tries to crack a password by generating a huge number of every possible combinations very fast.
Just add some Salt
We can protect against that with… salt! No, this is not just a superstition.
You may have heard of salt. It makes food tastier. It also makes passwords stronger. A salt is a hash that only the server knows. It works as following:
secretPassword + salt56Fyd => huuuuuuuuuuuuuuugeHashHx70
This is the equivalent of the user choosing a strong password with lots of special characters. No free hash tables can crack that!
A salt mechanism will not protect you against brute force attacks, though. A brute force attack happens when someone tries to crack a password by generating a huge number of every possible combinations very fast. Here are some examples of protection mechanisms which we all may have encountered at some point:
1. Forcing the user to introduce a strong password with special characters, a mix of uppercase and lowercase, numbers etc. (very annoying)
2. Forcing the user to introduce a password different than the last n passwords (even more annoying)
3. Introducing a captcha with some numbers
4. Introducing a captcha with some numbers and letters that not even a human can read
5. Showing some dancing animals and asking the user to identify one (I’m not inventing this)
6. Locking the account for a while after a few attempts (nice and simple)
Introducing CRUD basics
One of the best thing you can do for your users is to use an “always exclude, select when required” approach for the querying. Here’s an example using mongoose ORM:
userSchema = {
nickname: { type: String },
email: { type: String, select: false}
}
Users.findOne().exec() ⇒ {nickname: “johndoe”}
Users.findOne().select(‘+email’).exec() ⇒ {nickname: “johndoe”, email: “[email protected]”}
Another commonly overlooked aspect is data sanitization. Data sanitization is all about not allowing code to be injected in the database. To illustrate the importance of this, let’s look over two simple examples.
So now you can sleep better at night, knowing that some private user data will not accidentally “slip out”.
EXAMPLE 1
Imagine you have a SQL database in which you keep articles. Articles can be public or secret and they can be long or short. You get all the articles like this:
“SELECT * FROM posts WHERE isSecret=false AND isShort=”+requestParams.isShort
Now ask yourself, what would happen if someone would send a request with:
isShort=“true OR isSecret=true”.
The result will be all the articles that are either short and public, or… secret. This is an example of SQL injection.
EXAMPLE 2
The second example shows what can happen when some code gets stored in the database, even if the code may seem harmless. This is real:
When social networks appeared, people were crazy about personal page customization. Some apps allowed entering HTML code in the personal description to make it more attractive (this was a trend at some point). One hacker decided to enter this script in the personal description:
send(myPersonalData).to(someAddress) & copy(thisScript).to(myProfileDescription);
Now ask yourself: what happens when you visit the attacker’s profile? And what happens when someone visits your profile after that?
You can map out an entire social network like that. This type of attack is called cross site scripting (XSS) and it’s the most common type of web attack. The example above is a persistent XSS attack, because the malicious code resides in the database.
Server level
The number of unsecured databases out there is through the roof and rising fast! Don’t be a contributor to that! Here is a quick checklist for securing your database:
- Keep the database on the same server as the app
- Create a root user and password. Choose a strong password
- Create a user and password for each client
- Give only the minimal required permissions for clients (assign permissions incrementally)
- Lock the database port to the “outside world” (iptables and ufw work great)
- Set up a periodically backup mechanism
Don’t miss the next articles from Andrei’s series! He is going to share with you a lot of other valuable tips about web security. Now that you know how to secure databases, the next article will show what API security is all about. For instance, securing a form only in the browser doesn’t mean your system is all safe. Best results come when API security happens from inside out, as in from back end to front end validations. Stay close to find out more!
Want to keep up with the news? Read more on our blog or follow us on Facebook or Instagram accounts if you want to learn more cool tech stuff or find out about frameworks for innovation.
No Comments