Web applications can be susceptible to all sorts of vulnerabilities: a web application can be vulnerable to at least one of the 2017 OWASP Top 10 vulnerabilities, it can have remote or local file inclusion flaws or be vulnerable to other types of weaknesses. A web application can even be compromised by utilizing social engineering – there are all sorts of ways.

With that being said, web applications can also be configured in ways that make them vulnerable. Such a vulnerability is known as security misconfiguration – it occupies the sixth place on the OWASP Top 10 list.

Is security misconfiguration dangerous?

So, is security misconfiguration dangerous? Lets see what OWASP thinks:

Threat Agents / Attack Vectors		Security Weakness		Impacts
App Specific	Exploitability: 3	Prevalence: 3	Detectability: 3	Technical: 2	Business: ?
Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.		Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Automated scanners are useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services, legacy options, etc.		Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise. The business impact depends on the protection needs of the application and data.

We can see that OWASP describes security misconfiguration very broadly, so in order to better understand the importance of such a flaw, I will talk about each of the three points covering separate important issues.

The attack vectors

Now that I covered what security misconfiguration is, the next thing that we should probably do is understand how the occurrence of such a vulnerability might look like in a web application.

A web application might be vulnerable to security misconfiguration if:

• Default usernames and / or passwords are used in order to administer a web application
• Setup (installation) pages are not removed when a particular framework or a content management system is installed
• A web application has directory listing enabled
• Error messages are not customized before being shown

The anatomy of security misconfiguration

In order to better understand the risk of security misconfiguration, I will show how such a vulnerability might be exploited in a web application. Imagine you have a vulnerable web application, the website has a link to its administration control panel in the header easily observable by everyone, and you click it. You might see an authentication page that asks you to log in in order to access the administration control panel, however, you might also see this:

This web server has directory listing enabled – enabling directory listing might allow an attacker to access files that could have sensitive information, such as database login credentials, stored in them. In this case, the attacker could also access a file which might hold information about the users of the service.

In order to disable directory listing, create a .htaccess file with the following:

Options -Indexes

Problem solved.

Securing a web application upon installation

When a framework or a content management system is installed, it is best to remove the installation directory entirely. Not doing so might leave your website susceptible to security flaws. For example, in 2013, vBulletin announced that an exploit vector has been found in the vBulletin 4.1+ and vBulletin 5+ installation directories and advised their customers to remove the directories in question – should their customers have deleted the installation directories straight after installing the system, such a risk would not have been an issue.

Another thing worth mentioning is that you should change all (if any) default credentials that might be set upon installing a system – should you fail to do so, a potential attacker could gain unauthorized access to your web application. People might assume that the default combinations of credentials are simply not known to malicious parties which is not always the case – attackers know such things and are taking advantage of it.

Customize your error messages

Want to see a really bad error message? Here you go:

The above error message is terrible from a security point of view. But why? What an attacker might be able to do with that information? Well, take a guess.

A nefarious party might not get much use knowing the source of the file, but what he can do is utilize an SQL injection attack because the error is telling him that the web application might be vulnerable to such a flaw. And that’s all it takes. Just by looking at such an error, the attacker got enough information to compromise a system.

So, how can developers combat such issues? It’s actually pretty simple – as a rule of thumb, error pages should never display unnecessary information. The same error page can look like this:

From a security point of view, having such an error page on display is a good thing because a potential attacker could not gain insight into any potentially sensitive information that he (or she) might be interested in.

Summary

It is hard to exactly define what security misconfiguration is – such a vulnerability might involve a range of different issues, but generally, those issues can be tackled by applying basic security measures such as changing default passwords when a framework or a content system is used, disabling directory listing, removing install pages when a particular system is installed, not displaying unnecessary information and using the principle of least privilege when dealing with databases – such a flaw can be mitigated fairly easily.