🏗️ The Wrong First Button, Everything Crumbles! OWASP #4, Insecure Design

Hello! 👋 In our OWASP Top 10 Conquest Series, today we’ll discuss A04:2021-Insecure Design, which newly emerged in 2021 and garnered everyone’s attention.

This item doesn’t deal with a single line of code bug, but rather a fundamental problem where the design itself is flawed from the outset. No matter how sturdily a house is built with good materials, it’s useless if the blueprint omits a front door lock, right? 📜✍️ Similarly, ‘Insecure Design’ is a very important and serious issue that is extremely difficult and costly to fix later.

🤔 Insecure Design? What is it?

‘Insecure Design’ refers to all types of vulnerabilities that arise from not sufficiently considering security threats during the planning and design phases of software.

This contrasts with other OWASP items that primarily focus on ‘Insecure Implementation‘.

• Insecure Implementation: The design was good, but the developer made a coding mistake. (e.g., The blueprint says ‘steel lock’, but it was actually made with a ‘plastic toy lock’.)
• Insecure Design: The blueprint itself was flawed from the beginning. (e.g., The blueprint completely omitted the ‘front door lock’.)

In other words, any feature created without asking the question, “How could this feature be exploited?” can be a result of ‘Insecure Design’. This item highlights the importance of the ‘Shift-Left’ concept, where security is considered from the early stages of development.

---

🕵️‍♂️ Common Examples of Insecure Design

In what cases can we say a ‘design is insecure’?

1. Lack of Threat Modeling

This is the most fundamental problem. Just as one considers ‘how a thief might enter’ or ‘how to evacuate in case of fire’ before building a house, the process of identifying potential security threats and establishing countermeasures before designing a system is called threat modeling.

• Problem: If development begins without threat modeling, features are created without knowing “What are our service’s critical assets?” or “Who can attack and how?” 😥❓
• Result: Defense logic for predictable attacks (e.g., infinite attempts for password recovery) is omitted from the design.

2. Flawed Business Logic

This occurs when there are no bugs in the code itself, but the service’s workflow can be exploited.

• Example 🛒💸:

1. Add a 100,000 won item A and a 1,000 won item B to the shopping cart in an online store.
2. Apply a 50% discount coupon that only applies to the 1,000 won item B. (Total payment: 100,500 won)
3. Just before payment, delete the 1,000 won item B from the cart.
4. If the system design is flawed, the 50% discount might still be applied to the 100,000 won item A, resulting in a payment of 50,000 won.

3. Lack of Rate Limiting

This is a design problem where the system does not limit the number of requests per hour for a specific function.

• Problem: What if you could try entering passwords indefinitely on a login page? An attacker could use automated tools to quickly try billions of passwords and hijack an account. (Brute-force attack) 💣
• Necessity: Rate limiting, such as “Account locked for 10 minutes after 5 failed login attempts” or “Limit API requests to 100 per minute,” must be considered at the design stage.

4. Untrusted Client-Side Control

This is a dangerous design where security validation is performed only on the user’s browser (client) and not on the server.

• Problem: Let’s assume that a price field is disabled using JavaScript so that it cannot be modified. While regular users cannot modify it, an attacker can easily bypass this restriction using browser developer tools or proxy tools and send a price of 0 to the server. 😲
• Principle: “Never trust the client.” All critical data validation and authorization checks must be designed to be performed again on the server.

---

🛡️ How can we design securely?

1. Adopt a Secure Software Development Life Cycle (Secure SDLC) 🔄: Security activities must be naturally integrated into all stages of development, including requirements analysis, design, development, testing, and deployment. Security is not a feature to be added after development is complete.
2. Regular Threat Modeling 🧠💡: Foster a culture where team members discuss and brainstorm “What is the worst-case scenario for this feature?” every time a new feature is designed. Utilizing proven methodologies like STRIDE and DREAD is recommended.
3. Use Secure Design Patterns:

• Principle of Least Privilege: Grant only the minimum necessary permissions to all components and users.
• Defense in Depth: Design multiple layers of security so that if one defense line is breached, the next line can stop the attack.
• Minimize Attack Surface: Minimize exposed functions or APIs to reduce potential attack points.

1. Iterative Review and Improvement: Design is not a one-time process. The created design should be reviewed with colleagues, and the design should be continuously improved as new threat information emerges.

---

✨ Conclusion

Insecure design is like a “congenital heart defect” in an application. If discovered later, surgery is very complex and risky. Conversely, considering threats and designing securely in the early stages of development is the most effective way to prevent major future disasters with minimal effort.

Remember the saying, “Well-made code comes from secure design,” and let’s all approach development with the mindset of a ‘security architect’!