OWASP Top 10 in 2021: Insecure Design Practical Overview

Insecure design is #4 in the current OWASP top Ten Most Critical Web Application Security Risks.

Application Security Series
Monday, October 18, 2021

This category of OWASP weaknesses focuses on risks related to application architecture and design flaws. This category is quite broad and covers 40 CWEs related to application design.

Do you want to have an in-depth understanding of all modern aspects of
Insecure Design?
Read this article and bookmark it to get back later, we regularly update this page.

Designing the application in a secure way and anticipating possible attack vectors is an important step in the CI/CD pipeline. Implementation of Secure Development Lifecycle (SDLC) is an important process that can ensure your application safety by design.

What is Insecure Design?

The Insecure design category maps 40 CWEs that are related to input valuation errors, proper usage of application APIs and functions, privilege management issues and IDOR vulnerabilities, security of communication with the application, secure storage of sensitive information.

This new OWASP category anticipates broad negotiations with business and implementation of threat modeling stage in order to anticipate attack vectors and properly protect the web application.

Impact

Insecure application design can have severe consequences for the business, as it may allow attackers interfere with the application logic and lead to sensitive information disclosure or web application compromise.

Recent cases of IDOR vulnerabilities in WordPress plugins demonstrate how easy it is to take over the web application.

Example

Let’s have a quick look at the vulnerability in Fancy Product Designer WordPress plugin, known as CVE-2021-24370. The vulnerability in question is unauthenticated upload of arbitrary files (CWE-434), which was used in the wild in May 2021.

Fancy Product Designer is a WordPress plugin that allows users to upload images and PDF files. The plugin implemented filename sanitization during file upload, checked for proper content type of the file and checked if the file has a dangerous extension.

The issue however was that the filename that was passed from the attacker was first checked for dangerous file extension and after that the filename was sanitized.

An attacker could use the “anyfile.p h p” (with spaces in the file extension) to pass the FPD_Image_Utils::sanitize_filename() method checks from fpd-image-utils, since the “.p h p” file extension is not considered dangerous.

After that however the filename is sanitized and all special characters, including spaces are removed from it, which results in the anyfile.php being uploaded with the needed extension to the server.

Therefore, the HTTP POST request to exploit the vulnerability would look like this:

After successful upload the file was renamed using md5 hashing algorithm the “.php” file extension.

Solution

Here are the steps that can be helpful when designing your application:

• Implement SDLC to help evaluate and design security and privacy-related controls
• Implement a library of secure design patterns and use it across your application
• Evaluate application authentication process, access control, business logic and use threat modelling to identify possible attack vectors.
• Create integration tests and checks to validate that all critical flows are resistant to the designed threat model.
• Pay attention to resources and limit their consumption by the service user

Application Security Series Latest news and insights on AI and Machine Learning for application security testing, web, mobile and IoT security vulnerabilities, and application penetration testing.