We @ ASPIA frequently check all the input fields, injection, XSS, and other areas for large and visible problems while assessing the security risks and vulnerabilities of your applications.
But take note! You still need to review your application’s design.
These flaws are present in your application but frequently go unnoticed because they operate in the background. Insecure design, a new addition to the OWASP Top 10 for 2021, is frequently disregarded in favor of more widespread traditional vulnerabilities.
What is insecure design?
Breaking this name into two gives us insecure and design, where insecure means flawed, mistakenly made, and cannot be protected while the procedure is anything created by using our mind and in this case code. Getting them together gives us a design that isn’t secure and doesn’t incorporate security measures into the application at every stage of development.
Since the application was not created with security in mind, this brings broad-reaching and long-lasting effects on security. And hence this vulnerability relates to how a developer creates programs, designs solutions, and uses security procedures.
Some noteworthy Common Weakness Enumerations (CWEs):
- CWE-209: Sensitive information included in the error message
- CWE-256: Unprotected Storage of Credentials
- CWE-501: Trust Boundary Violation
- CWE-522: Insufficiently Protected Credentials under this vulnerability.
Impacts of Insecure Design:
The ineffective and absent control design susceptibility of insecure design explains a wide range of flaws.
It’s important to realize that insecure design differs significantly from insecure implementation as one attempts to understand its meaning.
A problem brought on by insecure design cannot be resolved by altering the implementation procedure, and vice versa. Its effects include hackers using important data, changing essential parameters, and even jeopardizing application security.
Attackers may also be able to take administrative-style control of the program or software, depending on the severity of the attack.
Examples
The three sample scenarios that follow explore further how such flaws could infiltrate the development process and end up being used by attackers.
Example1:
The application is designed to have an admin portal accessible at https://mytestwebsite/admin/myadmin. This is easily discoverable by any attacker and can be targeted and exploited to gain sensitive information which should only be accessible to the admin.
This could even get easier on finding directory enumeration using DIRBUSTER.
Example2:
What if your application accepts characters like >, ‘, or = on its login and authentication pages with no sanitization?
The attacker will then be able to insert his malicious code, which may be approved by the server to react maliciously. He can then continue running his malicious scripts in it and attempting to access or obtain sensitive data.
Example3:
Applications nowadays are using third-party plugins and APIs to make the application more responsive and functional but what if any of these third-party plugins have an insecure design and is not maintained then it will lead to making the whole application vulnerable.
Suppose an attacker found out that the application is using a vulnerable WordPress plugin like the wp-file-manger plugin with a version before 6.0 then he can easily enter his malicious PHP code to get into the website, as stated in CVE-2020-25213.
How to mitigate this vulnerability?
- To assess and build security and privacy-related measures, establish and use a safe development lifecycle with application security experts.
- Create and make use of a library of secure design patterns or ready-to-use components.
- For crucial key flows, business logic, access control, and authentication use threat modeling.
- While working on your software development lifecycle, incorporate security language and controls into user stories.
- Integrate plausibility checks at each tier of your application ranging from your front end to back-end.
- Create unit and integration tests to confirm that all important flows are resistant to the threat model. For each level of your program, compile both proper and improper use cases.
- Depending on the necessity for exposure and protection, divide the system and network layers into tier layers.
- Limit resource consumption by user or service.
Conclusion:
Now that we are fully aware of this issue, we should all recognize that the foundational stage must always be error-free in order for us to develop a secure product.
Similarly to this, always check that the project’s concept is secure before writing any code. Only then can the team create a decent, useful project and identify the vulnerability beforehand.
