Insecure Design Vulnerability
Play Agnostic Labs on this vulnerability with SecureFlag!
Description
Insecure design refers to flaws that arise during an application’s design and architecture phase. Before any code is written, decisions about how the application will work can create security weaknesses that persist throughout the lifecycle.
Design flaws are important to recognize as they set the foundation of the entire application. Common examples include missing input validation, exposing sensitive information, or failing to enforce secure communication.
By integrating security best practices and threat modeling early in the design phase, teams can identify and mitigate risks before they become costly or exploitable issues.
Impact
As these security weaknesses are built into the foundation, their impact can be severe and far-reaching. They may cause functionality issues, broken policies, data leaks, or even full compromise of the application. These flaws can increase the attack surface, giving potential threats more opportunities to exploit the system.
Prevention
The design of an application sets the direction for the whole development process, so making sure that the design is secure is critical. This is often called being ‘Secure by Design’; building security in from the very start rather than later.
Designing securely requires:
-
Reviewing design and architecture with security best practices in mind. The design phase is the most cost-efficient place to find issues before they become serious problems.
-
Reusing proven architectural patterns instead of reinventing the wheel. If the team lacks expertise, bringing in outside guidance or a second opinion can help.
-
Using threat modeling to map out possible attack scenarios and identify weaknesses early.
-
Having clear policies, standards, and documentation provides development teams with practical guidelines to follow.
-
Making sure the design is implemented securely, following industry standards and methods.
-
Developing unit and integration tests alongside the application to validate both functionality and security.
-
Promoting a security mindset across teams. Secure design isn’t only the architect’s job; it’s something everyone in the SDLC needs to consider to deliver safe applications.
Threat Modeling
Threat modeling is the process of identifying and prioritizing potential threats to a system and then determining how much value different security controls would bring in reducing those threats.
OWASP describes threat modeling as a way to “identify, communicate, and understand threats and mitigations” to software applications. In practice, it’s a structured way to find issues early and limit the damage they could cause.
It also requires a mindset shift, where you need to “think like a hacker.” Viewing the tech stack through this lens allows you to see where the application is at risk and then implement measures to reduce or remove the risk.
Integrating threat modeling into the software development lifecycle (SDLC) from the start makes a huge difference when it comes to security. Also, finding risks early means mitigating them is faster and far more effective.
When modeling systems in real life, it helps to lean on an established methodology such as STRIDE, PASTA, TRIKE, or OCTAVE.
Threat Model Labs
In our labs, we follow a simplified process based on the fundamental steps of threat modeling:
Define trust boundaries: Identify the system’s components and how they interact with each other and external entities.
Identify threats: Determine potential attacks that could exploit the system.
Select security controls: Choose measures that reduce or eliminate each identified threat.
Trust Boundaries
A trust boundary is an imaginary line that separates areas with different security policies or levels of trust.
Trust boundaries can appear in many places, for example:
-
In an application, separating roles such as “User” and “Administrator” with different access rights.
-
In a network, dividing zones such as “Local Server,” “Intranet,” “Internet-facing,” and “Internet.”
-
In organizational environments, distinguishing between “Cloud,” “Staging,” and “Production” systems.
Defining trust boundaries helps identify which components are most at risk and where security controls should be applied.
Threats
A threat is any potential action or event that could compromise a system’s security, integrity, or availability. Threats can come from many sources, including external attackers, insider threats, or even accidental mistakes.
Identifying all possible threats is an important step in understanding what vulnerabilities exist and how they might be exploited. This allows teams to plan effective measures to reduce or prevent those risks.
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. This can be a technical measure, like using antivirus software, or a process, like setting up access controls. The goal is to make the system safer and keep risks at 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 at mass revenue loss. If an attacker exploits this flaw to fully book the business without intending to use the services, it could result in significant revenue loss. This could have been prevented by requiring a deposit or the submission of valid credit card details with associated identification.
Testing
During the definition and design stages, it’s essential to define and test security requirements, i.e., understanding how the application should work from a security perspective.
Applications should have a documented design and architecture. Use Unified Modeling Language (UML) models to show how the system works, and then perform a threat modeling exercise. Apply the findings to review the design with the systems architect and update it as needed.
- OWASP ASVS: 1
- OWASP Testing Guide: Definition and Design