Security Misconfigurations

Overview

Security misconfigurations refer to incorrect or inadequate configuration settings in various components of an application stack, which can lead to vulnerabilities and increased risk of attack. This can occur in network services, platforms, web servers, application servers, databases, frameworks, custom code, pre-installed virtual machines, containers, and storage.

Description

One of the most common webmaster flaws is keeping the CMS default configurations. This can make the CMS vulnerable to various automated attacks that rely on default settings. To mitigate such attacks, it is important to change the default settings when installing a CMS, including adjusting settings related to comments, users, and user information visibility. Additionally, file permissions should be hardened by modifying default settings. It is crucial to have a secure installation system in place to prevent security misconfigurations. This involves a repeatable hardening process, minimal platform with no unused features, regular review and update of configurations, segmented application architecture, and sending security directives to clients. An automated process should be implemented to verify the effectiveness of configurations and settings in all environments.

How to Prevent ?

To prevent security misconfigurations, it is recommended to: - Establish a repeatable hardening process for deploying secure environments quickly. Configure development, QA, and production environments identically with different credentials. - Remove or avoid installing unused features and frameworks. - Review and update configurations regularly, addressing security notes, updates, and patches. Pay special attention to cloud storage permissions. - Implement a segmented application architecture for effective separation between components or tenants using techniques like segmentation, containerization, or cloud security groups. - Send security directives to clients, such as Security Headers. - Automate the process of verifying the effectiveness of configurations and settings in all environments.

Example Attack Scenarios:

• Scenario #1: Default Sample Applications:  The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws that attackers exploit to compromise the server. If default accounts and passwords are not changed, an attacker can easily log in and take over the system.

• Scenario #2: Directory Listing Enabled:  Directory listing is not disabled on the server, allowing an attacker to simply list directories. They can then download and decompile the compiled Java classes to view the code. This exposes serious access control flaws in the application.

• Scenario #3: Detailed Error Messages:  The application server's configuration allows detailed error messages, including stack traces, to be returned to users. This exposes sensitive information and potential underlying flaws, such as vulnerable component versions.

• Scenario #4: Default Sharing Permissions in Cloud Storage:  A cloud service provider has default sharing permissions open to the Internet by other CSP users. This enables unauthorized access to stored sensitive data within cloud storage.