A04:2021 – Insecure Design ![icon](png/top_10_icons_final_insecure_design.png)
Factors
CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs |
---|---|---|---|---|---|---|---|---|
40 | 24.19% | 3.00% | 6.46 | 6.78 | 77.25% | 42.51% | 262,407 | 2,691 |
Overview
A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures. As a community we need to move beyond "shift-left" in the coding space to pre-code activities that are critical for the principles of Secure by Design. Notable Common Weakness Enumerations (CWEs) include CWE-209: Generation of Error Message Containing Sensitive Information, CWE-256: Unprotected Storage of Credentials, CWE-501: Trust Boundary Violation, and CWE-522: Insufficiently Protected Credentials.
Description
Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks. One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.
Requirements and Resource Management
Collect and negotiate the business requirements for an application with the business, including the protection requirements concerning confidentiality, integrity, availability, and authenticity of all data assets and the expected business logic. Take into account how exposed your application will be and if you need segregation of tenants (additionally to access control). Compile the technical requirements, including functional and non-functional security requirements. Plan and negotiate the budget covering all design, build, testing, and operation, including security activities.
Secure Design
Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. Threat modeling should be integrated into refinement sessions (or similar activities); look for changes in data flows and access control or other security controls. In the user story development determine the correct flow and failure states, ensure they are well understood and agreed upon by responsible and impacted parties. Analyze assumptions and conditions for expected and failure flows, ensure they are still accurate and desirable. Determine how to validate the assumptions and enforce conditions needed for proper behaviors. Ensure the results are documented in the user story. Learn from mistakes and offer positive incentives to promote improvements. Secure design is neither an add-on nor a tool that you can add to software.
Secure Development Lifecycle
Secure software requires a secure development lifecycle, some form of secure design pattern, paved road methodology, secured component library, tooling, and threat modeling. Reach out for your security specialists at the beginning of a software project throughout the whole project and maintenance of your software. Consider leveraging the OWASP Software Assurance Maturity Model (SAMM) to help structure your secure software development efforts.
How to Prevent
-
Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls
-
Establish and use a library of secure design patterns or paved road ready to use components
-
Use threat modeling for critical authentication, access control, business logic, and key flows
-
Integrate security language and controls into user stories
-
Integrate plausibility checks at each tier of your application (from frontend to backend)
-
Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases and misuse-cases for each tier of your application.
-
Segregate tier layers on the system and network layers depending on the exposure and protection needs
-
Segregate tenants robustly by design throughout all tiers
-
Limit resource consumption by user or service
Example Attack Scenarios
Scenario #1: A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers, which is why they are prohibited. Such code should be removed and replaced with a more secure design.
Scenario #2: A cinema chain allows group booking discounts and has a maximum of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they could book six hundred seats and all cinemas at once in a few requests, causing a massive loss of income.
Scenario #3: A retail chain’s e-commerce website does not have protection against bots run by scalpers buying high-end video cards to resell auction websites. This creates terrible publicity for the video card makers and retail chain owners and enduring bad blood with enthusiasts who cannot obtain these cards at any price. Careful anti-bot design and domain logic rules, such as purchases made within a few seconds of availability, might identify inauthentic purchases and rejected such transactions.
References
List of Mapped CWEs
CWE-73 External Control of File Name or Path
CWE-183 Permissive List of Allowed Inputs
CWE-209 Generation of Error Message Containing Sensitive Information
CWE-213 Exposure of Sensitive Information Due to Incompatible Policies
CWE-235 Improper Handling of Extra Parameters
CWE-256 Unprotected Storage of Credentials
CWE-257 Storing Passwords in a Recoverable Format
CWE-266 Incorrect Privilege Assignment
CWE-269 Improper Privilege Management
CWE-280 Improper Handling of Insufficient Permissions or Privileges
CWE-311 Missing Encryption of Sensitive Data
CWE-312 Cleartext Storage of Sensitive Information
CWE-313 Cleartext Storage in a File or on Disk
CWE-316 Cleartext Storage of Sensitive Information in Memory
CWE-419 Unprotected Primary Channel
CWE-430 Deployment of Wrong Handler
CWE-434 Unrestricted Upload of File with Dangerous Type
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
CWE-451 User Interface (UI) Misrepresentation of Critical Information
CWE-472 External Control of Assumed-Immutable Web Parameter
CWE-501 Trust Boundary Violation
CWE-522 Insufficiently Protected Credentials
CWE-525 Use of Web Browser Cache Containing Sensitive Information
CWE-539 Use of Persistent Cookies Containing Sensitive Information
CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session
CWE-598 Use of GET Request Method With Sensitive Query Strings
CWE-602 Client-Side Enforcement of Server-Side Security
CWE-642 External Control of Critical State Data
CWE-646 Reliance on File Name or Extension of Externally-Supplied File
CWE-650 Trusting HTTP Permission Methods on the Server Side
CWE-653 Insufficient Compartmentalization
CWE-656 Reliance on Security Through Obscurity
CWE-657 Violation of Secure Design Principles
CWE-799 Improper Control of Interaction Frequency
CWE-807 Reliance on Untrusted Inputs in a Security Decision
CWE-841 Improper Enforcement of Behavioral Workflow
CWE-927 Use of Implicit Intent for Sensitive Communication
CWE-1021 Improper Restriction of Rendered UI Layers or Frames