When building an application, we must assume that it will be exposed to attackers at all times and may be misused by ordinary recipients. The danger of the first group seems obvious, but what kind of risk a standard user brings? You must know that attempts to “cheat the system” are quite common, especially in the e-commerce industry. There is a group of users who count, for example, on errors in calculating discounts or the number of elements. You can expect that if you have an online store, there will be at least a few people who will try to use your site in such a way to find a vulnerability. Therefore, we must be really careful when building an application. We cannot count on everyone to act according to our plan. A secure application is the one in which the author assumes the opposite scenario - such that everyone wants to find a vulnerability in our system. Only such an approach, and then appropriate protection, can give us at least a substitute of security.
We will try to approach the topic from a slightly easier side - what are the best practices for writing secure web applications? There are many of them, but here we’ll cover some very basic rules to keep in mind.
Hide sensitive data
This may seem obvious to you but the passwords for our accounts are so important that we should protect them as tightly as possible. If you make a test app and keep it in your repository you can say it doesn’t matter. However, have you really not used this password somewhere? Attackers know very well that most internet users often use the same combination of characters. So you can expose yourself to the fact that someone will try to use the login data found, e.g. on Twitter or Google account. So instead of setting the password directly in the configuration files in your codebase, you can use a reference to an environment variable
However, when others can look into the code, they are able to point out those security issues, maybe even fix it. That’s why hiding the code makes it harder to fix than to break. Moreover, though that keeping your server code on the repository, even without passwords, can be risky. If your script has any vulnerabilities, the hacker will be able to easily detect them, and then attack the application published, for example, to download data from the database using it.
Hiding your password won’t do anything if it’s just weak. It is worth to remember that attackers often operate on powerful hardware that makes code-cracking applications extremely efficient. How can we protect ourselves against it? The attack called “Dictionary Attack” tries the most popular combinations from words that already exist. That can be phrases or words from the dictionary. The most efficient way to fight against this attack is to use a password containing at least 14 characters that include special characters, numbers, letters lower and upper cases. It is also very important to not use the same password for everything, they must be all different. Password manager, such as LastPass can be useful. However, this is the minimum that we should stick to. It is difficult to create an exact list of requirements, as these often change, e.g. until recently it was a very popular practice to force users to periodically change their password. Meanwhile, Microsoft says, based on its experience, that this approach does more harm than good. Out of laziness, users choose almost identical passwords anyway, changing only one of the last characters, which is why, for example, in their new guidelines for Office 365, the technological giant recommends abandoning this idea.
Always validate the data also on the server
Try… catch mistakes
Keep your web app updated
It is better to use popular and valued packages. Pay attention to the number of editions, downloads and the date of the last update. The package must be still supported. Then, even if any gaps are found, they should be patched quickly.
Avoid packages that the author himself describes as deprecated. Even if you think a package is perfect for your needs, it’s quite possible that in many cases it won’t work properly with your code. Also, there is a good chance that it has some security flaws. Remember that IT is an extremely dynamic industry. Also to avoid vulnerabilities that are present in any framework or library, you should make sure you actually use all the libraries integrated into your software and use the latest version of each library, if it’s stable.
Security Tools that may be useful to you
If any gaps are found, the authors of the packages try to patch them. For your app to take advantage of these changes (fixes), you need to update them as needed. Unfortunately, we often have so many of them that checking each of them manually would be quite a breakneck task. So a good solution may be to use a tool called Snyk. It automatically checks the GitHub repository and reports on possible dangers. You can use it online at this link.
In addition to the above good practices, the use of the helmet package is standard. Its task is to properly set the HTTP headers so that our server is less vulnerable to attacks. A description of all functionalities can be found at here. Take this package as a basis and something that will as much as possible hamper attacks that could take advantage of the weaknesses of the header settings.
The more extensive and complex the application, the more vulnerabilities are in it. If its role is sensitive (e.g. creating a bank’s website), we will be exposed to more attacks, and these can often be extremely sophisticated. So we are not able to prepare ourselves for a threat in 100%. Nevertheless, we must try to minimize the danger. Securing your applications is very important and the industry is constantly evolving. Important systems must be analyzed on an ongoing basis and, if necessary, adjusted to deal with new forms of attacks. Only this approach gives us a relatively large guarantee as to safety.
If you think we can help in improving the security of your firmware or you
looking for someone who can boost your product by leveraging advanced features
of used hardware platform, feel free to book a call with
us or drop us email to
contact<at>3mdeb<dot>com. If you are interested in similar content feel free
to sign up to our newsletter