OWASP Top 10: Insecure Design

Most vulnerabilities listed in the OWASP Top 10 are caused by errors during the development stage of the Software Development Lifecycle (SDLC). A failure to follow secure coding best practices creates an exploitable security gap.

Insecure Design vulnerabilities are different because they fall earlier in the SDLC. Instead of implementing planned functionality incorrectly, software is architected in a way that violates security best practices or lacks key security features.

What is the Risk?

Insecure design is a broad category of vulnerabilities related to poor design of security controls. Some examples of vulnerabilities that fall into this category include the presence of sensitive data in error messages, violating trust boundaries, and inadequately protecting credentials against exposure.

Since this category covers any vulnerabilities caused by design errors rather than implementation errors, the potential risks are manifold. For example, poor credential storage could lead to a compromised user account, which results in the theft of sensitive data or fraudulent activities on a user account. Alternatively, an attacker may exploit design flaws to cause an application to crash or to collect sensitive information from error messages or other data leaks.

Examples of Attack Scenarios

Insecure design is a wide category of vulnerabilities that lends itself to various attack scenarios. A few examples of potential attack flows include the following:

Automated Attacks

Anti-bot defenses are an essential security control for certain operations within a web application. Scrapers, scalpers, and credential stuffers are all examples of automated attacks that cause damage to an organization and its customers.

A failure to implement defenses against these types of attacks would be considered a design flaw. As a result, an attacker may be able to buy up tickets to sell on a secondary market, collect valuable data from an organization’s site, or guess credentials to gain access to a user’s account.

Credential Theft

Several vulnerabilities related to insecure design deal with a failure to properly manage credentials. For example, passwords may be stored in plaintext or transmitted over the network in an insecure or unencrypted form.

In a web app, this may include the use of HTTP for login pages rather than encrypted and authenticated HTTPS. An attacker who can eavesdrop on a user’s interactions with the website could sniff these credentials, gaining access to their account.

Error Message Reconnaissance

Error messages tread a fine line between providing enough information for the user to understand what went wrong and revealing too much data to an attacker. If a web application provides too much detail in error messages, an attacker may be able to use this information to attack the system.

For example, if a web application prints the exact exception caught by backend code, then this exception could reveal information that is valuable to an attacker. This may include the precise install directory of the application (useful for directory traversal attacks) or the structure of an SQL command (valuable for SQL injection).

Case Study: Mirai Botnet

Mirai is one of the most famous Internet of Things (IoT) botnets in history. It performed large-scale attacks against various targets, including Dyn, a major DNS provider. This attack made websites inaccessible for millions of users in Europe and North America. After the botnet’s code was leaked, it was also used as the basis for many other botnets.

The scope and success of the Mirai botnet were made possible by design vulnerabilities in IoT devices. These systems were distributed with default passwords, which were known to attackers and rarely changed by consumers. With a list of only 61 username/password pairs, the Mirai botnet operator was able to access and infect approximately 400,000 devices to use in DDoS attacks.

How to Remediate Insecure Design Vulnerabilities

Insecure design vulnerabilities cover a wide variety of potential security flaws within an application. Some best practices to help avoid these issues include the following:

• Define Business Requirements: When designing an application, the development team should explicitly define the business requirements for the application. This helps define what the application needs to do, and, therefore, the potential security risks and required countermeasures.
• Perform Threat Modeling: Threat modeling should be used to identify potential security risks and attack vectors for critical processes. Examples include authentication, access control, and key business logic.
• Use Trusted Design Patterns: Most elements of a web application aren’t unique, and there’s no need to reinvent the wheel. Creating and using secure design patterns for various components reduces the risk of a design flaw.
• Create Security Requirements: When defining requirements, user stories, and test cases, create ones focused on security as well as functionality. For example, users need to be able to authenticate in a way that is user-friendly and doesn’t reveal their credentials to an attacker.
• Implement Security Best Practices: Certain components have security best practices that should be implemented for any application. For example, passwords should be salted and hashed for storage, web apps should use HTTPS, and rate limiting should protect authentication portals.
• Test Potential Attack Vectors: Threat modeling and security requirements should identify the various ways that an attacker could target a web application. Defenses should be put in place and then tested to verify their effectiveness.

How IONIX Can Help

The Insecure Design vulnerability class in the OWASP Top Ten covers a great deal of potential security risks. This increases the difficulty for development teams to ensure that their web applications are architected and secured correctly. At the same time, cybercriminals are familiar with common errors and aim to identify and exploit them in their attacks.

The IONIX platform helps organizations manage the security risks of OWASP vulnerabilities proactively. During a risk assessment, the platform performs simulated attacks to determine if a web application falls prey to the techniques and tools commonly used by cyber attackers. To learn more about how IONIX can help bolster your web app’s security against these types of attacks, book a free demo.