Disclaimer: I'm not a security expert, nor do I pretend to be one. This article just highlights some of the things that I've learned over the years, when it comes to basic security measures. I cannot be held responsible for the bad things that could happen to your app.
When I started out as a developer I didn't take into consideration the security aspects of my websites / apps. As most of my developer friends, I just loved to code.
It's the same story with every other new developer out there. We can safely assume that when it comes to building your first app or website, as a new developer, you won't think about basic security measures, because you ... still trust the world.
As someone who has been hacked, I've learned a thing or two about how to deal with certain things. So, how does one get on the path of a secure web app? Below are the do's and don'ts of what you should consider when building / setting up your app.
Don't ...
... save passwords in clear text in the database
This is quite common among new developers, even professional ones. I've encountered cases where passwords were saved in clear text in the database and everyone had the same password, with no difference between them whatsoever.
Imagine someone suddenly gains access to your database, either forcefully or you've added a new developer to the team. You have to be very trustworthy to actually let people see that information. They could use that information to gain access to other services.
If you continue reading you'll learn how you can solve this and why this is a bad habit.
... use admin as the default username
When you deploy your website or app, make sure you don't have the default username, or the first username saved in the database, as admin. Just make it to something else. You can't imagine how many bots I have encountered that targeted the admin username and tried to forcefully break into the app.
Someone can basically try to guess the password, since assuming the default username is admin, taking every combination possible and filling the input field with it, is really easy. Imagine how many server calls that takes and how it can affect your server's performance. In some cases it can even take your server offline.
... use the default table prefix
When it comes to websites or apps built using some form of CMS / e-commerce system, it's bad practice to use the default prefix when making the initial setup of the app.
If, for example, your app is vulnerable to SQL injection then an attacker can easily target sensitive tables in your database since they know the structure of your database and the prefix you're using.
My suggestion is to always use a different prefix, then the default one. If you're using something like WordPress, that the default prefix should be changed to something custom to the app you're currently building.
... use O (zero) as the first user ID
It's basically the same situation as the previous one. An attacker could possibly take control of the first user and rake havoc in your database and your app, because we all know that, in most cases the first user is also the admin and the one that has the biggest security clearance.
... use weak passwords
This should be common practice for everything not just the apps you're building, but the ones that you use as well. Enforcing strong passwords for all your users can increase your security tenfold.
Suggesting they use a password generator before they sign up or you generating a strong for them should to the trick.
This is a much broader discussion, that I'm not going to tackle in this article, however below there are a few suggestions on how you can fix this issue. My suggestion is to implement at least some of them.
Do ...
... enforce folder / file writing permissions
This is one of the most basic things you can do. Make sure your folders / files are owned by the right user:group combo and have the proper write permissions. Here is a great guide on how you can get started with that.
If your files and folders don't have the right permissions, then an attacker would be able to inject problematic scripts that could disrupt your setup and could endanger other users.
My suggestion, for starters, is to use 644 for files and 755 for folders, as write permissions, if you're using a Linux based system.
... use encrypted passwords
I've already explained what can happen when you save passwords in clear text. Now, I'm telling you, how you can solve that issue, because when it comes to passwords, you should always, always encrypt then, however you want, just do it.
I hope I don't need to enumerate why this is so important, just read this. But I can advise you, on how you can enforce a basic encryption system.
If, for example, you're using PHP you can use the hash function to encrypt the passwords. This is the first and most basic step. The next suggestion continues to improve upon this one.
... use a salting method for passwords
As mentioned above this is an extra step, to ensure that the passwords you save in your database are kept clear of prying eyes. This method is quite common and really easy to implement.
The Wiki explanation states the following:
In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes a password or passphrase. The primary function of salts is to defend against dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.
In case you didn't understand what the above words mean then here is the explanation for web applications.
You can implement this by generating a random string, that you have saved somewhere in a private file, you can take that string and concatenate it to the password, before you save it in the database, and then hash the whole thing. When you want to check if the user filled in the correct password you use the random string, that you generated, and you have saved in a secure file, add it to the value you get from the input field, hash it and compare it to the password that you have saved, in the database, for that user.
The benefits of using a method like this one is that it takes a very long time to crack a password using conventional methods.
... escape your data
Always, and I mean always escape your data, weather it's data that you output or something that you save in your database. You don't want malicious data saved in your database that in return you output to your users.
Why is this so important? The most common attack, if you don't escape your data, is an XSS attack. XSS will allow an attacker to inject client-side scripts into your app. When users view that they'll get injected with whatever is in those scripts.
Based on the language and database of your choosing, a method will be available that can help you achieve this. If you're using PHP, google for php escape and you'll find multiple methods.
... enable 2FA
Or if you prefer the long version, two factor authentication. This is a bit in the realm of high security apps. You don't really need to implement this right away, when building your app, but make it so that it's easier to integrate later on. So, what is 2FA?
It's an extra layer of security that requires not only a password and username but also something that only, the user has, for eg. a piece of information only they should know or have immediately on hand.
Since we're talking about web apps, the most common practice of implementing 2FA is to generate a QR code that contains some data. That data is saved in a token app that generates a one time token.
Each time a user fills in their username and password they should also input the token generated by the authenticator app. It's basically a second password that is generated on the go by the user and only they can see it. The system doesn't know it, so if an attacker tries to break in they'll have another layer to bypass.
This can also be achieved either by sending a token via SMS, via a phone call or via email. It can also be a token generated by some piece of hardware or the one that I described, a token generated by a piece of software.
What can be the main benefit of this? Well, the use of two distinct authentication factors can eliminate security concerns, that a system admin may have, around granting access based on a single, knowledge-based factor.
So there you have it. A list of do's and don'ts that you can follow when you build your app. Now, don't get me wrong, I know there are a lot more things you can implement, that I might have missed, but I just wanted to write a short overview of the things that you could implement inside your app. Should you consider them? Yes. Should you be paranoid about security? I would say, no. Or at least, not from the very beginning.
I'll just leave you with something to think about before I wrap this article up.
Distrust and concern are the parents of security.
~ Benjamin Franklin
Until next time, stay secure and don't forget to code long and prosper!
Stefan
Image credit: Guillaume Kurkdjian