When designing applications, developers are recommended to use secure design patterns, diligently planned threat modeling, and reference architectures that keep the application free of security gaps.
Lack of effective security controls in the design phase often results in an application being susceptible to many weaknesses, collectively known as insecure design vulnerabilities. This article discusses insecure design flaws, potential impacts, and mitigation strategies.
What is Insecure Design?
Insecure design encompasses various risks that arise from ignoring design and architectural best practices, starting from the planning phase before actual implementation. A quick point to note here is that an insecure design differs from an insecure implementation, and a near-perfect implementation cannot prevent defects arising from an insecure design. While the Insecure design flaw is a new entrant to the OWASP top 10, it ranks number four on the 2021 list since mitigating risks at the design phase is considered fundamental toward ‘Shift Left’ security practices.
What are Insecure Design Vulnerabilities?
Insecure design vulnerabilities arise when developers, QA, and/or security teams fail to anticipate and evaluate threats during the code design phase. These vulnerabilities are also a consequence of the non-adherence of security best practices while designing an application. As the threat landscape evolves, mitigating design vulnerabilities requires consistent threat modeling to prevent known attack methods. Without a secure design, it is difficult to detect and remediate architectural flaws such as:
Unprotected Storage of Credentials
When designing an application, development teams often ignore secret management and access control best practices, which lead to security vulnerabilities. As a result, the system commonly gets compromised because of harmful password management practices such as storing user passwords as plaintext in application properties, configuration files, or memory. Design flaws in identity and access management for certificate generation also enable access to confidential information. Such application security flaws would allow attackers to assume legitimate user accounts and obtain unauthorized access to password-protected resources for deeper system exploitation.
Trust Boundary Violations
A trust boundary is an interface in the program that allows for the safe exchange of data or commands between two entities. These include areas of the application that accept uncontrolled external inputs like HTTP requests, network sockets, and file uploads. Trust boundary violations occur when the interface accepts and stores both trusted and untrusted data inputs in the same data store. Developers often fail to distinguish between trusted and untrusted sources, enabling the exchange of malicious data and commands. In addition to this, the application’s backend may also allow the unsafe exchange of data across the trust boundary if the application lacks a diligently deployed input validation mechanism.
Generation of Error Messages Containing Sensitive Information
Most modern applications are designed to identify error conditions and generate diagnostic messages that inform the user of the error and possible remediation. Often these error messages are verbose and contain sensitive information like user id, password, the application environment, or other associated data that an attacker can access. The attacker can use the exposed data to launch other attacks like path transversal and SQL injection attacks.
Improper Isolation or Compartmentalization
This vulnerability occurs when the application does not effectively separate entities with varying rights, privileges, and access permissions – resulting in broken access control. Suppose developers fail to separate the environments of a product successfully. In that case, an attacker may gain access to any one of the environments and can further extend the scope of the attack to other environments. As a result, improper isolation of processes, resources, and application functionalities vulnerabilities leads to a giant attack blast radius.
Prevention Guide
Insecure Design Attacks Prevention Guide
Learn how to detect and prevent insecure design attacks.
How to Prevent Insecure Design Vulnerabilities?
Prevention of insecure design vulnerabilities typically starts with enforcing a ‘shift left’ security mindset that requires business risk profiling from the onset of the SDLC. Some common approaches to prevent insecure design vulnerabilities include:
Establish a Secure Development Lifecycle
During the application design phase, development teams should embrace factual design methodology and established design patterns. Each team member should have access to security tools, tested component libraries, and threat models to reduce their workload’s application security risk. Security teams should be engaged at the beginning of the development lifecycle and be consulted throughout the development, integration, and deployment phases.
Establish Continuous Unit and Integration Tests
Developers should set up automated security tests for individual functions and methods within the modules, components, and classes used in the application. Outlined test plans should be included as a part of the blueprint for the design and release of the product, ensuring airtight security across each stage of the SDLC.
Enforce Granular Requirement and Resource Management
During the initial planning phases of application development, product managers should collect and assess the client’s technical and business requirements, including availability, authenticity, integrity, and confidentiality of the application logic and data. Based on this, developer teams should determine the optimum segregation of tenants and exposure of each component within the application. The production plan should also cover the management of all development activities on a per-tenant basis to enforce secure management of access rights.
Implement System and Network Layer Tier Segregation
Organizations should determine the application’s protection and exposure needs to implement the appropriate level of segregation at the system or network layer. By partitioning the deployment into modular subsystems or virtual networks, it is easier to restrict the level of access to specific data and resources. This makes it challenging for hackers to extend their scope of access in case of an attack.
Impacts of Insecure Design
Consequences of attacks on insecure design vulnerabilities vary depending on the scope of the attack, the data exposed, and the duration it continues till detection. Potential impacts of a successful exploit include:
- User and system enumeration
- Complete account takeover
- System and data breaches
- Denial of service by spoofing a server with multiple requests
- Privilege escalation for compromised, low-privilege accounts
- The execution of other attacks such as cross-site scripting, cross-site request forgery, and path transversal
Examples of Insecure Design Vulnerabilities
Examples of attack scenarios leveraging insecure design include:
Verbose Error Message Leading to Path Transversal
Error messages that return detailed information may direct attackers to files that contain valuable information. Attackers can access the files and directories using path transversal techniques, enabling further compromise. The following code snippet shows a PHP database error that exposes the system structure to malicious users:
try {
openDbConnection();
}
//print exception message that includes exception message and configuration file location
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';
}From the above error message, the malicious user can access Mysql_config_location and obtain credentials to access the database or replace the configuration file with a malicious one.
Injection As a Trust Boundary Violation Vulnerability
In an application that uses an SQL database without adequate validation, an attacker can inject malicious code to retrieve data from the database. Assume a car rental website using the following URL for clients looking to lease an SUV:
https://darwin-cars.com/vehicles?category=SUV
Clicking on the link instructs the application to construct a query for retrieving details of the relevant vehicles from the database, as shown below:
SELECT * FROM vehicles WHERE type = ‘SUV’ AND registered=1This query asks the backend to return all details from the vehicles table, where the category is SUV, and the value of the registered column is 1. The restriction registered=1 is used to hide existing vehicles that have not been registered.
In the absence of user-supplied URL validation, the malicious user can construct a URL like:
https://darwin-cars.com/vehicles?category=SUV’-
This sends the following query to the database:
SELECT * FROM vehicles WHERE type= ‘SUV’--’ AND registered = 1The — characters indicate the start of a comment in SQL, so the server interprets the rest of the query as a comment. By commenting out registered= 1 part of the query, the attacker forces the server to return details of all vehicles in the SUV category, even the unregistered ones.
How Crashtest Security Can Help Prevent Insecure Design
The Crashtest Security Suite includes comprehensive capabilities to secure applications throughout the SDLC. These include:
Automated Penetration Testing
Crashtest Security offers an automated penetration testing tool that enables continuous testing across all stages of the application development process. This helps in efficient threat modeling while reducing the application’s attack surfaces and mitigating imminent threats.
Continuous Vulnerability Scanning
The platform includes vulnerability scanners for most of the known attack vectors to help organizations eliminate security blind spots missed during the design and planning phases.
Security Assessments, Reports, and Benchmarks
Crashtest Security’s vulnerability scanner offers actionable reports after thoroughly assessing the application by benchmarking against the OWASP top 10. Reports also include recommendations for a secure design pattern and application architecture to enhance security hygiene.
