Insecure Design
Play Labs on this vulnerability with SecureFlag!
Description
Insecure design is a category unto itself. It differs from the bulk of the vulnerability classes available in SecureFlag’s suite of exercises since, rather than being a specific flaw resulting in an exploitable vulnerability; it refers to the genesis of the application development cycle itself. It is integral to the design and architecture phase, even before any code has been written. Poor decisions during a project’s initial phase can result in lasting, potentially grave ramifications leading to functional failures, compromise, and beyond.
Insecure design, however, should not be understood as the sole root cause for all development vulnerabilities since vulnerabilities originate from both design and implementation choices. Common design vulnerabilities include a lack of input validation controls, sensitive information disclosure, and missing secure communication layers.
By enforcing a comprehensive design stage that accommodates relevant security best practices, we can rule out many issues before they cause any problems.
Impact
At the start of every development project, design choices are made that set the tone for the remaining lifecycle. Flawed designs will negatively impact applications and are often the cause of significant disruptions in functionality or, worse, broken policies, information disclosure, and even complete compromise.
Prevention
As the design of an application inevitably dictates its development process, ensuring the stated design is ‘secure’ is paramount. ‘Secure by Design’ is an oft-used term to describe this mindset and practice of baking in security at the outset of any technological process.
Designing securely requires:
-
The revision of the design and architecture in accordance with best practices. Identifying security flaws in the design phase is the most cost-efficient place to weed out issues and make changes with benign impact.
-
That the wheel not be reinvented. Secure architectural patterns are well-studied in industry and academia. External expertise can be leveraged if the in-house team is not knowledgeable enough or a second opinion is warranted.
-
Threat Modeling to be used as a structured approach to map potential threat scenarios and identify application weaknesses.
-
Ensuring that appropriate policies, standards, and documentation are in place. Documentation is vital as it gives development teams guidelines and policies they can follow.
-
The design is to be implemented securely using industry standards and methods. There is no point in having a secure design if it is not implemented correctly.
-
Unit and integration tests to be developed together with the application.
-
Security language and mindset to be a part of non-security practitioners’ stories. Secure by design is not the sole responsibility of the designer; rather, it is a team effort that demands all those working across the SDLC be au fait with the need to consider security as a key to a successful delivery to production.
Threat Modeling
Threat modeling is the process of identifying and prioritizing potential threats to a system and determining the value that possible security controls would have in reducing or neutralizing those threats. OWASP describes threat modeling as a way to “identify, communicate, and understand threats and mitigations” to software applications. It provides a systematic and structured way to find threats early and minimize the possible damage they may cause if realized.
Threat modeling needs you to “think like a hacker”; viewing the technological stack through this lens can allow us to identify where our application is at risk and then implement measures to mitigate or eliminate such risk accordingly.
Integrating threat modeling into software from the beginning of the software development lifecycle (SDLC) is crucial. Early identification and mitigation of application security risks are essential to make the application more secure.
When modeling systems in real life, consider adopting a widely accepted threat modeling methodology, like STRIDE, PASTA, TRIKE, or OCTAVE.
Threat Model Labs
In our Labs, we use a simplified process based on the Threat Modeling fundamental steps:
- Define the trust boundaries in the target system by analyzing its constituent parts to understand how they interact with each other and external entities.
- Identify the threats that could attack the application.
- Identify the security controls to mitigate the threat level.
Trust Boundaries
A trust boundary is a conceptual line that separates areas with different security policies or levels of trust.
It is applicable in multiple contexts, such as defining the privileges in logical functionalities, where different roles like “User” and “Administrator” possess distinct access rights. They can also divide a network based on their trustworthiness, e.g., “Local Server,” “Intranet,” “Internet-facing,” and “Internet.” This concept extends to organizational environments too, where environments such as “Cloud,” “Staging,” and “Production” require distinct levels of trust.
Defining trust boundaries helps to identify components susceptible to threats and where to implement security controls.
Threats
A threat refers to a potential negative action or event that could compromise a system’s security, integrity, or availability. Threats can come from various sources, including external attackers, insider threats, or even inadvertent errors.
Enumerating all possible threats is a key step in understanding what vulnerabilities exist and how they might be exploited, allowing for the development of mitigation strategies to protect the system.
Extensive threat descriptions are cataloged in projects such as the MITRE CAPEC project.
Controls
A security control is a safeguard or countermeasure implemented to mitigate identified threats. They can be technological measures like installing anti-virus systems, but they can also be procedural, like implementing access control. The goal is to reduce the risk associated with various threats to an acceptable level.
Scenarios
Scenario #1
Management has provided you with a plan for a new web and mobile application that sends and receives many API server calls to provide the content.
They marked the web page to use HTTP with TLS; however, all the calls to the API server omit the TLS aspect. This missing communication between the planning and development teams could result in all the API calls being transmitted in plaintext, causing sensitive information to be revealed.
Scenario #2
Any site that allows mass bookings to occur without needing a deposit or credit card details is potentially looking down the barrel of mass revenue loss. Suppose an attacker exploits a flawed functionality such as this to fully book the business without intending to use the supplied services. In that case, it could result in the business losing a large amount of revenue. It would have been possible to prevent this by implementing a deposit requirement or by requiring the submission of valid credit card details with associated identification.
Testing
During the Definition and Design, defining and testing security requirements is essential, i.e., determining how an application works from a security perspective.
Applications should have a documented design and architecture. Use Unified Modeling Language (UML) models to describe how the application works and undertake a Threat Modeling exercise. Use the results to revisit the design and architecture with the Systems Architect to modify the design.
- OWASP ASVS: 1
- OWASP Testing Guide: Definition and Design