Duis vehicula hendrerit finibus. In hac habitasse platea dictumst. Quisque aliquet, lacus eget feugiat viverra, diam dui dapibus mauris, at vehicula diam sem vitae nibh.
Security Misconfiguration is somewhat of an umbrella term that covers common vulnerabilities that come into play because of an application’s configuration settings, rather than bad code. It’s a wide-ranging subject and it’s heavily dependent on factors like your technology stack.
Often times addressing these issues is something that seems simple, like changing a configuration file or even a single line of code, but the impact and consequences of these vulnerabilities can be severe.
Let’s take a look at some of the categories below.
Webserver
A classic misconfiguration on web servers is the enabling of Directory Listing.
While there's often little to no direct impact of having Directory Listing enabled, it does make it easy for an attacker to discover other mistakes that might also exist. These could be things like pages that were intentionally hidden, backup files, and other similar items.
It’s worth noting that all of those things themselves are inherently poor practices, too, and count as security by obscurity.
Directory Listing is trivial to disable and adds defense in depth by making it more expensive for an attacker to enumerate the host to find potential attack vectors against it.
Most frameworks offer a "debug" mode for developers. This mode, among other things, will usually show stacktrace details when an unhandled exception occurs. Some frameworks even show you snippets of code alongside the stacktrace. This can be immensely helpful as you’re developing, but can also provide attackers with a lot of information that they really shouldn't have access to.
Monitoring endpoints
Many frameworks also have a set of endpoints that can be enabled which allows for monitoring of the application, whether that's in a production or test/dev environment.
These can include:
While this information is not usually sensitive, it can still provide details that help potential attackers gain a better understanding of your application. Of course, your environment or logs may actually contain sensitive information, so it’s important to be mindful of what could be visible and utilized if prying eyes happened upon it.
The distinction between production versus non-production environments
People frequently make the mistake of not following the guidelines like disabling directory listing, debug mode, and debug endpoints in dev/test environments, and do so only in production environments. The rationale is that these non-production systems are meant for testing and getting the information provided by these features is important.
This mentality is misguided, however. Attackers are still able to probe and disclose information from non-prod systems, then utilize the information gathered from the test system to then attack your production system. It's also not uncommon to find companies that use copies of their production database in test systems, which increases the risk even further.
XXE
One type of security misconfiguration that’s very severe is XML External Entities (XXE).
This occurs when you parse from untrusted sources with entity resolution enabled, which historically has been the case. XXE can lead to arbitrary file read, and server-side request forgery, among other things.
Check out the example below for more details and a simple example of this one in particular.
We secure software through developer-driven security at the start of the software development lifecycle.
Visit Secure Code Warrior
