Security Misconfiguration

Issue

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.

Impact

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.

Is My Application Vulnerable

The application might be vulnerable if the application is:

  • Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.

  • Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges).

  • Default accounts and their passwords still enabled and unchanged.

  • Error handling reveals stack traces or other overly informative error messages to users.

  • For upgraded systems, latest security features are disabled or not configured securely.

  • The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.

  • The server does not send security headers or directives or they are not set to secure values.

  • The software is out of date or vulnerable (see Using Components with Known Vulnerabilities).

Without a concerted, repeatable application security configuration process, systems are at a higher risk.

Example Attacks

Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren't changed the attacker logs in with default passwords and takes over.

Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.

Scenario #3: The application server's configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.

Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

Solution

Here are a number of excellent reference points