We assume here that your hosting environment is already secure, whether managed by yourself or by a hosting provider.
Let’s focus on the applications. What steps can you take to improve the security of a web application? How to reduce the attack surface and remove easily detectable risks? This article does not pretend to be the manual of the perfect web application defender, but recalls basic principles and presents a list of items to be considered and applied on a regular basis.
1. Have a strong enterprise security policy
The first breach can be a simple human error, and can really make the attacker’s life easier: weak passwords, security related information itself not secure enough (like passwords stored in a text file on your desktop or on a post-it), wrong access level… all of this needs to be cleaned so as not to leave the front door wide open.
Often mentioned but rarely applied: passwords strength. Not too short, include digits, uppercase characters, and special characters. This simple rule should be applied everywhere and should not sound like a new recommendation, but when having a look at password databases, it appears that passwords actually used are really weak, whether it’s for personal use or for professional access controls providing access to powerful functions or to confidential or sensitive data.
This is all about basic security rules, and about processes to be defined and applied. A bit boring, indeed, but crucial.
2. Remove useless portions of your web application
Before diving into the security of your web applications, maybe you can reduce the potential attack surface by simply reducing the number of applications you have, in production or even in your staging environment. Are you sure all the websites your company owns are really used? Maybe there is kind of an old web application that uselessly exposes data for only a few people, and that can actually be a risk for your global web environment? These questions are also valid for webservices, or APIs. Such exposed items, non used and poorly secured are open doors for bad guys.
So, make the inventory of your web applications and services arsenal, you might found some of them don’t deserve security, just shut them down.
3. Update your libraries, and use reputable ones
It seems that 80 % of the code used in web applications is actually made of external libraries that you did not develop.
It is therefore necessary to perform several maintenance operations on these libraries:
– First, ensure these libraries included in your applications are really used and deserve maintenance. Again, don’t spend money things you don’t need.
– Then, ensure these libraries are well-known, recognised by the open source community as reliable and trustworthy. Would you install a library on your server that contains vulnerable code or malicious features? What if that library steals your data and sends it to a bad guy’s server? Beware of what you download and include in your applications.
in 2011, 26% or downloaded libraries where vulnerable and known as vulnerable (1). Of course, that’s quite comfortable to rely on existing code during your development, to reduce the workload of your developers, but precaution is better than cure.
– Last but not least, maintain your libraries. Open source is great, because it’s free to download the code, but there is a maintenance cost that you can’t get rid of. When the community discovers flaws, it is generally made public and therefore usable by anyone. Of course that’s even worse when the library is a commercial one… So check regularly if your libraries have updates, test them and install them on your web applications. You will also find tools that can tell you when an update is made available.
4. Ensure no sensitive data about your architecture leaks
Another type of vulnerability directly caused by “human errors”: information leakage related to you application itself. A web developer might be tempted or even prompted to copy/paste a piece of code on a forum, in order to get help from outside your organisation during the development of a new module. Attackers usually try to grab a maximum of information about their target on these forums, pastebin or newsgroups. The risk is to have tons of information about you web application (code, plugin version, libraries, processes, business logic) that leak on the Internet.
To be cleaned asap, and stop talking too much!
5. Review critical business processes
Maybe you should also review your application internal processes (business logic). Is your password recovery process reliable? Are you sure it cannot be used by an attacker to easily modify or grab your users’ passwords? Why spending a lot of money on a credit card validation service if users can in fact modify their shopping cart after they check out?
These flaws really exist, and it is not always about technical things or code, but essentially about business login and logical controls. Web security starts during the functional design of the application.
So how to ensure everything is fine with your business logic and processes? List the critical functions of you application and review them to ensure there is no way to circumvent the mechanics. It is not about verifying that everything works fine in a pre-defined scenario, but about trying to abuse the system, detecting vulnerabilities and fixing them.
6. Review sensitive data protection
First, make an inventory of all the data managed by your web application: emails, passwords, PII data (Personally Identifiable Information), payment data, transactions data…
Even if you have very little data to protect on your website, the simple fact of having a stolen password can be serious: that password might be valid on other websites your user is registered on, and can be used by an attacker for subsequent attacks. Whether your are a big multinational company or a little e-commerce website operating alone doesn’t matter, your users or consumers deserve that you protect their data.
“Less if more”: Collect only the data you need, not more! Collecting too many data will first be quite boring for your users since they will have to fill-in long forms, which is time consuming, but worse, the more data you collect, the more exposed your users are. Limiting the amount of collected data is therefore needed.
The same reasoning applies to the duration of data retention. Do you need to keep the whole set of data in your system? How much time do you keep it?
How do you handle that data? Are they collected in a secure manner (forms that submit the data over a secured wire like SSL)? How does the data transit from one point to another, whether it’s during internal transfers or with third parties?
We won’t discuss that point further here, but a real data security policy must be put in place, and applied. A lot of resources on that subject exist, and many companies can help you on these subjects. Our services include that type of technical review.
7. Perform code reviews focused on security
Security must of course be included in your web Software Development Life Cycle (SDLC). As an example, you should perform code review focused on security, and not only on software architecture. Web security knowledge is of course needed in order to run these code reviews successfully. Reviewing code without having the basics of web security will probably not give good results.
A good starting point is to read or reread the Owasp Top 10, as well as the various cheat sheets, which will recall the developers what the security best practices are, and will sharpen their vision on web security challenges. Code reviews must be performed in teams, with people who did not develop the code to be reviewed.
You can also build security check-lists that will be used during the development and that can be specific to the programming language used in a the project.
8. Run a penetration test
There’s nothing like a penetration test if you want to test the resilience of your application. That’s like the final exam! A pentest will allow you to see which vulnerabilities are in your application, to realise how they can be exploited and how far a simple flaw can drive you to. A single flaw can open the door to subsequent vulnerabilities or even compromise a whole web environment.
Such a security audit can help you see at one point in time how your web application is secure.
View more about web penetration tests.
9. Prepare yourself for the worse scenario
It is not possible to make a web application 100% secure, unless you actually remove it. Security is a tradeoff, and has a cost. It’s about assessing the risks and answering with an appropriate risk response, with an adequate level of security.
New attack techniques and vulnerabilities frequently appear, so “best practices” must also evolve. The web world is not perfect, it is therefore necessary to anticipate the unexpected, and thus develop a risk response to the following: “What if my website, despite all the efforts we’ve made, get attacked?”
A contingency plan must be prepared, to face the worse situation: plan all the necessary steps to be followed in case of hacking, backups, data restoration, actions to be performed in case the website is defaced after an attack, identify where the attack comes from and the way it has been performed so as to fix the vulnerability that let the bad guy come in, communication plan.
10. Do the above regularly!
Well, we’ve reach number #10 of the list. What else can be done? Lots of things, but you can already plan to do the above again, and again. Security is not a one time event. First, your web applications evolve, new applications will come in your web environment, so you must regularly check that your web security level is on top. Also, you should know that effective security measures at a given time will not necessary be strong enough in a few months or years. Technologies evolve, so do attack methods. The MD5 encoding has been considered as a good practice for a long time, and as a safe way to protect passwords, but it’s now wrong.