While performing software security assessments I have all too often run into developers that are constantly trying to explain away vulnerability findings. They spend way too much time trying to justify the code they have written and explain why it doesn’t need to be changed. All kinds of reasons are given. For example, the access is guarded by a network security device. If an intruder gains access to this we have bigger problems to deal with. While this could be true it is a mode of thinking that can lead to disaster when code is not written to be defensive.
I’d like to challenge developers to lay aside the “it can’t happen” attitude and instead have a “what if it does happen” mindset. Use the energy that it takes to explain away a risk to come up with a solution that will avoid the problem should it arise.
Three questions that a developer can ask themselves and address the answers head on will result in more secure software. They are:
- What would happen?
- What should happen?
- What could happen?
Let’s take a closer look at each of these.
- What Would Happen?
- As a developer ask yourself “what would happen if the levels of defense outside my code are breached and an intruder gets to this point?” Taking a close look at the answer to this question can reveal some sobering things about the code you are analyzing. Take simple steps to validate input and avoid revealing information that is not required or that the intruder should not be allowed to see.
- What Should Happen?
- Ask yourself, “what should happen if the levels of defense outside my code are breached and an intruder gets to this point?” Think not about how it is not possible for an intruder to get to this point but rather, on what would happen if they did. Spend the time to correct the issue and rest assured in the fact that your code is covered should it ever happen.
- What Could Happen?
- Ask yourself “what could happen if I take the steps to prevent such vulnerabilities in the code that I am writing?”. What could happen is that an intruder that gets through outer layers of protection is then blocked by secure code that you’ve written thus preventing a security breach.
These questions can lead you to thinking more about how to secure your code and less about what is protecting your application outside your code.
