Factors
| CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs |
|---|---|---|---|---|---|---|---|---|
| 20 | 19.84% | 4.51% | 8.12 | 6.56 | 89.58% | 44.84% | 208,387 | 789 |
Overview
Moving up from #6 in the previous edition, 90% of applications weretested for some form of misconfiguration, with an average incidence rate of 4.%, and over 208k occurrences of a Common Weakness Enumeration (CWE) in this risk category. With more shifts into highly configurable software, it's not surprising to see this category move up.Notable CWEs included are CWE-16 Configuration and CWE-611 ImproperRestriction of XML External Entity Reference.
Description
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 are still enabled and unchanged.
Error handling reveals stack traces or other overly informative error messages to users.
For upgraded systems, the 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., are 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 A06:2021-Vulnerable and Outdated Components).
Without a concerted, repeatable application security configurationprocess, systems are at a higher risk.
How to Prevent
Secure installation processes should be implemented, including:
A repeatable hardening process makes it fast and easy to deploy another environment that is appropriately locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to set up a new secure environment.
A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process (see A06:2021-Vulnerable and Outdated Components). Review cloud storage permissions (e.g., S3 bucket permissions).
A segmented application architecture provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups (ACLs).
Sending security directives to clients, e.g., Security Headers.
An automated process to verify the effectiveness of the configurations and settings in all environments.
Example Attack Scenarios
Scenario #1: The application server comes with sample applicationsnot removed from the production server. These sample applications haveknown security flaws attackers use to compromise the server. Suppose oneof these applications is the admin console, and default accounts weren'tchanged. In that case, the attacker logs in with default passwords andtakes over.
Scenario #2: Directory listing is not disabled on the server. Anattacker discovers they can simply list directories. The attacker findsand downloads the compiled Java classes, which they decompile andreverse engineer to view the code. The attacker then finds a severeaccess control flaw in the application.
Scenario #3: The application server's configuration allows detailederror messages, e.g., stack traces, to be returned to users. Thispotentially exposes sensitive information or underlying flaws such ascomponent versions that are known to be vulnerable.
Scenario #4: A cloud service provider (CSP) has default sharingpermissions open to the Internet by other CSP users. This allowssensitive data stored within cloud storage to be accessed.
References
OWASP Testing Guide: Configuration Management
OWASP Testing Guide: Testing for Error Codes
Application Security Verification Standard V14 Configuration
List of Mapped CWEs
CWE-11 ASP.NET Misconfiguration: Creating Debug Binary
CWE-13 ASP.NET Misconfiguration: Password in Configuration File
CWE-15 External Control of System or Configuration Setting
CWE-260 Password in Configuration File
CWE-315 Cleartext Storage of Sensitive Information in a Cookie
CWE-520 .NET Misconfiguration: Use of Impersonation
CWE-526 Exposure of Sensitive Information Through Environmental Variables
CWE-537 Java Runtime Error Message Containing Sensitive Information
CWE-541 Inclusion of Sensitive Information in an Include File
CWE-547 Use of Hard-coded, Security-relevant Constants
CWE-611 Improper Restriction of XML External Entity Reference
CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
CWE-756 Missing Custom Error Page
CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
CWE-942 Permissive Cross-domain Policy with Untrusted Domains
CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag
CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration
CWE-1174 ASP.NET Misconfiguration: Improper Model Validation
