Introduction
Planning is the most important part, not just in our lives and work but also in software design. Before you undertake a big project, I am sure there must be a requirements document based-off which you start to conceptualize things and plan them before writing the code.
Now as they say: a house with a weak foundation is also weak and cannot withstand adverse conditions. The same is the case with the software and services too: if the design is not resilient, the applications might not be able to withstand malicious users in an attack scenario or even a normal user-base at times of high load.
The planning and design phases must be given careful consideration. Otherwise, as things proceed, it becomes difficult to change the core decisions. Makes sense right…
Insecure Design
As you already would have understood; these issues happen when the application is not designed with security in mind.
It’s a new add-on to the OWASP Top 10 family but it’s a great add-on I suppose. If things are done wrong all sorts of issues can happen. Won’t they?
- Missing user input bounds can lead to issues like buffer overflows
- Usage of unsafe APIs or functions can result in compromise: think of using random numbers without any seed for instance or extracting an archive without taking into consideration the absolute or relative paths that the embedded files can have.
- Applications making use of elevated privileges than required.
These are just some examples but this is a really vast category. If you don’t do proper threat modeling or follow secure design patterns and principles, it’s quite easy to shoot yourself in the foot.
Note for the “Responsible Developers”: It’s not always the interns who mess up, but we as general should take collective responsibility for this yeah?
The Fix of Insecure Design
I am sure you must have heard a lot about the Shift Left mentality. What it means is that in the Software Development Lifecycle (SDLC), we move towards the left that is, to the earlier phases of software development: the planning and the design stage. This is where the crucial designs about the application take place and thus if we mess up here, then the application won’t be secure.
Think of it as the blueprint for a house. If the blueprint is not well thought out, then a lot of issues would crop up at the later stages — foundation or the different parts of the house might not be strong, durable, or resistant to bad weather conditions.
The same is the case with the software you design. If the designs are not well-rounded, they will bite you back. And this is where shift-left mentality really helps: you think of all the issues that could crop up are already thought of and the design decisions are made to avoid any pitfalls in the later stages when the applications are being brought to life.
As we move to the right (to the later stages of SDLC), making changes become more and more difficult as things solidify if you will. More work is required at the later stages to undo the things and rewrite the code. Trust me, that’s not something that you would want to do. Ask yourself if you would be comfortable enough to reconstruct a house that is almost about to get finalized. Tough job right: both in terms of money and time. Software is the same in this regard.
Other measures that you can take are:
- Follow best practices, wherever possible
- Build things with security-centric mindset
- Secure design principles must be followed and adhered to for the lifetime of the application/services
- Code reviews must be done thoroughly to avoid any bad code going into the production
- Regular code audits and pentests are a good way to ensure the security of your products. It’s a general advice that would help detect and mitigate most of the trivial issues.
These measures are all good measures that you must follow in order to maintain the high security of your services and software.
Playground
One interesting lab that immediately comes to my mind is our FREE CTF (yes it’s totally FREE!):
API Security CTF: [Nov 20–24]: https://attackdefense.com/challengedetails?cid=2114
I had also done a write-up covering the different ways to solve it.
So I would say why not give it a shot and see how far you can go without referencing the solution.
Closing Thoughts
Before I conclude this post, I would just say that this list by OWASP is still a draft, and therefore don’t just follow it blindly, let it settle for a while, and let things be confirmed. But on the flip side, I think it’s a quite good list and things might not change much. That’s why I am trying to cover this list this early 😀
I hope you enjoyed this post and I will see you next time while covering the other vulnerabilities from the new OWASP Top 10 list.
