In the fourth entry of our ten-part blog series on the OWASP Top Ten list, we are taking a brief look at Insecure Design. Insecure Design as a category of vulnerabilities is a new edition to the OWASP Top Ten list when compared to historical versions. The category itself is considered quite broad in terms of the number of vulnerabilities that can occur if a web application is afflicted by an insecure design.
It should be noted that there is a difference between insecure design and insecure implementation. For example, a developer building a new web application may have implemented an SQL database and taken care to sanitise user input, as well as ensuring the libraries used by the web application are constantly patched up to date. We can say that efforts have been made to ensure a secure implementation.
However, if that selfsame developer forgot to remove an admin login page with default credentials from the domain, an attacker could very easily locate and abuse that page’s availability. In this instance, no matter how well our developer has done in implementing and securing the various functions and features available to a user, the web application has been published with an insecure design at its core.
Rather than a tool or plugin, secure design is more of a mindset and methodological approach to building a web application. This could be analysing the risk to the application once live due to its exposure or your own organisations reach, the technical requirements and capabilities of the application, or ensuring a robust testing schedule before changes are pushed to the live build.
Common Examples of Insecure Design.
The list below is non-exhaustive, but details some of the common issues that can be considered as insecure design:
- Lack of Least Privilege.
- Any system that affords more access than is necessary to its users can often be a big risk. For example, a public facing web application may have access to a database. Generally, a regular user would be given read-only access to the content stored within the database. However, if a regular user instead has full read-write access, malicious actions such as data modification could be carried out.
- Allowing Brute Force attempts.
- Whilst designing a new web application, if the developers do not account for the possibility of brute force attacks or deem it unnecessary to protect against them, it becomes an instance of insecure design.
- Exploitable processes.
- A web application might have been developed to allow the booking of seats at a venue. If secure design principles are followed during development, it is quite likely that the need for a deposit is apparent. For instance, if no deposit has been put in place as a requirement, an attacker could limit test the booking feature and possibly book out large quantities of seats with no intention of paying for them.
Prevention of Insecure Design.
When building an application or system, it is important to put in place and follow security-minded principles and procedures. This could be:
- The implementation of threat modeling for business logic, access control and key flows.
- Limiting the resource consumption allowed for users or services.
- Choosing and following one of the many “secure development lifecycle” options available.
- Constantly re-assess the likely attack vectors in the product, such as identifying key libraries, technologies, or important account.
- It is always useful to ensure that regular training is offered and delivered to employees. Developers should find it useful if updated on the latest threats that may target relevant systems for example.
On top of trying to prevent instances of insecure design, it is also important to consider the possibility that an application may have been built in such a way and is already live. In that instance, it is recommended to consider a penetration test, which can go a long way in identifying areas of insecure design and advising on the best mitigation.