This article is the 5th episode of our series dedicated to understanding web application vulnerabilities quickly, without necessarily having a technical background.
We will talk today about “Security Misconfiguration”. The name might sound quite generic to you and that’s actually the case since this type of vulnerability encompasses several types of flaws. However all these vulnerabilities are linked to the same origin: a lack of maintenance or a lack of attention on how the web application environment is configured.
This kind of vulnerabilities is ranked number 5 on the OWASP Top 10 2013, meaning it’s one of the 10 security items web developers need to focus on.


Illustration - trou de sécurité

The objective of this article is to avoid going too technical so we’ll keep quite generic. What must be kept in mind is that a website does not run by itself and relies on many components.
Several “layers” make the web application work, from the network infrastructure to code libraries that are used to build the application:

Network layer (all components that make your website accessible to the whole world, or not)

  • Server layer (the machine that hosts your website)
  • Operating System layer (Windows, Linux…)
  • Application layer (IIS server, Apache… the software component that holds your website)
  • Libraries layer (code that is ready to use, and is part of your website)
  • Your website itself.

All these layers have their own security settings, security aspects and potential vulnerabilities.

As an example, default accounts enabled in some components, whether it’s a database or a web server, are very dangerous. Many default accounts using “administrator” as a login and “password” as a password are still provided with software or servers, and absolutely need to be removed when added to your web environment.
Another simple example is the “directory listing”, which allows files to be listed on a specific location, like the root folder of your website, making it possible to get source code or many assets.

What is the consequence?

If you web application suffers from such security holes, the consequences can be quite severe, depending on what your application is and depending on the exact flaw.
It generally gives attackers access to data you do not want to disclose, or access to unauthorized features. It can also result in a complete system compromise, letting the attacker do whatever they want on your system (stealing the database, changing business processing rules, installing worms, shutting down your website or deleting it…)

How to avoid such vulnerabilities?

1. A good security level begins with a properly designed architecture that ensures a good separation between the different components of your platform (database, application server…).

2. Adopting an automated or repeatable process to setup new web environments or to add servers. Using checklists can also be a good practice. The objective here is to ensure that setting up new servers or services will not introduce new vulnerabilities.
In any case, these processes and checklists must be maintained and reviewed by a real team that includes hardware and network architects, and software architects. Working alone on such a mechanism is definitely not a good idea.

3. Ensuring you have a strong maintenance policy is also a key success item for your web application security. Setting up servers and applications properly will not be very effective if you don’t update them regularly. Operating systems, firmwares, libraries, the web programming language processor itself (like PHP)… all these items must be kept up-to-date so as to make sure new vulnerabilities (made public quickly) will not be exploited on your system.
You probably heard about the Heartbleed vulnerability. Attackers started exploiting the vulnerability massively as soon as it was made public (and even some before it was made public). Updating the Open SSL library is one of the steps to avoid exploitation of the vulnerability on your server, if you use Open SSL. If you don’t do it, your website is vulnerable to any attack around sensitive data you might have protected with SSL.

4. Running a security audit, web application pentest is also critical, to make sure you did not forget anything and get a confirmation that your platform is secure enough!
Contact us for more information on this, VAADATA provides web application penetration testing services.

These flaws do not only affect production environments. Any other existing QA, staging, pre-production or development environment (the list is not exhaustive) must also be properly managed, since attackers might be able to launch attacks on them.

Other articles in this series: