Security Misconfigurations: The Soft Underbelly of Web Applications

What Are Security Misconfigurations?

Security misconfigurations are a very wide category of security risks, basically covering everything that is not directly related to vulnerable code. They often provide attackers with their first foothold in the target system, so it’s no surprise that the Open Web Application Security Project has included them in the OWASP Top 10 as a major risk factor for web applications.

At any level of the application stack, missing patches and security updates are a fundamental risk, especially since attackers can easily check for known vulnerabilities in server-side components. Last year’s remote code execution vulnerability in Oracle WebLogic Server is one example of an application server issue that must be promptly patched to prevent an insecure configuration. Secure settings should also be applied at the application framework and runtime level, for example to enforce stricter syntax or disable potentially insecure functions.

For a web server, an insecure configuration can mean missing or misconfigured HTTP security headers that leave applications vulnerable to well-known and avoidable attacks. It could also mean running the server process from a privileged account or using default security settings in production environments. The same applies to database servers, where default credentials and access settings from local development environments often make it into production server configurations. Insecure cloud storage (such as publicly accessible S3 buckets) is another common source of data breaches.

The Consequences of Security Misconfigurations

You can check your application code all you like, but if there are any gaps in the complex machinery that makes it work, the application will be vulnerable. Everything in cybersecurity is connected, so even seemingly minor or irrelevant misconfigurations may add up to serious security flaws attackers can exploit. Access control misconfigurations, such as the use of default accounts or default passwords, can give miscreants unauthorized access to application functionality and sensitive data. Serious access control flaws may even allow cybercriminals to access an admin console or other privileged functionality, paving the way to account manipulation, code execution, or complete system compromise.

Misconfigurations can also give attackers direct access unprotected files, revealing sensitive information, intellectual property, or technical data that can be used for further attacks. For example, an attacker may be able to download application source code directly or obtain the bytecode (such as Java class files) and then reverse-engineer it to extract custom code. This can happen if the web server allows directory listing or can be made to access files outside the web root directory, for instance, through a path traversal vulnerability combined with broken access control.

Information exposure during error handling provides a vital source of intelligence for attackers. Error messages can reveal a lot about technologies, versions, and internal implementation details, especially if the app server configuration allows stack traces to be displayed. However, error messages can also indirectly reveal information about the results of attack payloads. Even such limited feedback as the type of error or time taken to return it can be enough to execute blind SQL injection and other blind attacks.

Some HTTP security headers are specifically designed to mitigate attacks such as cross-site scripting (XSS), cross-frame scripting (XFS), and clickjacking. If these headers are missing, you are, quite simply, asking for trouble, as even unskilled attackers may be able to exploit well-known vulnerabilities. At the same time, the consequences of misconfiguring security headers can range from a false sense of security (if a header is present but not doing anything) to breaking application functionality with the wrong CSP directives or even rendering a site or application permanently inaccessible to users due to a misconfigured HSTS header.

How To Detect and Prevent Web Application Security Misconfigurations

While high-profile breaches and exciting new attack techniques tend to dominate cybersecurity headlines, preventing misconfigurations is a less glamorous yet fundamental area. Correctly setting up the HTTP security headers is one easy way to quickly improve security. Basic system hardening is another essential best practice for any deployment. This should include disabling all unnecessary features and potentially insecure default options, changing default credentials, and removing unnecessary services. A production deployment should also be stripped of all test data, redundant assets (especially sample applications), and any debug functionality or embedded credentials that may have been used to ease development. 

Having a strong application architecture and well-defined development and testing workflows makes it easier to ensure secure separation of application components and data. To prevent future misconfigurations, a repeatable security configuration process should be defined and followed. This is especially important in modern containerized deployments where a misconfigured image can make its way into multiple applications.

To regularly check if your application is configured securely at every level, you need a way of running scans that test web application security across the entire stack, from custom code and dependencies to web server settings. This is where a modern DAST solution like Invicti is invaluable because it probes every part of the application just as an attacker would. Invicti not only accurately detects vulnerabilities and checks if they are exploitable but also comes with the Technologies feature to identify outdated technologies and unused application stack components. By incorporating Invicti scans into your security routine, you can quickly detect misconfigurations and remedy them to stay secure.