Fixing a bug is not just fixing a bug.
There’s more to it than meets the eye…
Building is harder than breaking. Well, at least most of the time. Building a quality software takes months maybe not years. And I’m not aware of a security weakness finding which takes a few weeks let alone months. Having said this I also have to admit that I don’t have any first-hand government level, cyber warfare exploit experience. So, what do I know… Nevertheless, A similar comparison is possible with fixing and hacking. Most of the time the fixing might seem easier, but it’s not. There are various difficulties a developer has to tackle to mitigate a security bug.
This is your host Bedirhan here and I’ll try to list the annoying but fruitful actions to follow when eradicating a security bug in your software. We don’t want to get rid of just the symptoms but the problem for good.
Once in a while we, developers, come across with a security bug ticket assigned to us. Some of these bugs are the results of dynamic efforts where tests are executed against the running application, whereas, others are the results of static efforts where tests are executed against the code, resting. No matter what the origin is, like ordinary bugs, the security bugs better be handled with the following actions in mind…
- Understand the bug
- Find the root of the bug
- Find the right fix
- Search for similar bugs through the application
- Generalize protection mechanisms
- Add a unit test
Understand the bug
Any fool can know. The point is to understand. A. Einstein.
The first thing facing a security bug is to understand it. Security reports produced by automatic tools almost always include helpful description and mitigation details giving insights, however, may not be enough.
And if this is the first time you see a bug with name “Cross Site Request Forgery (CSRF)”, then it’s probably the best to go out the Google or better yet, if exists, your security department (not physical security department but your information security team) and ask their help to understand fully. As developers we tend to over trust ourselves, so don’t fall into that trap. Ask for details you don’t understand. Chances are you will do follow this process not so many times, as you grasp the details of each different types of security bugs (unless the code you work on sucks).
Find the root of the bug
It is in the roots, not the branches, that a tree’s greatest strength lies. M. Dhliwayo
Understanding the bug is the most important part of fixing it, however, finding the root of it is the second. Please don’t fail to go on and try to find a fix immediately after you understand the problem.
For example, when we figure out from the security bug report that users shouldn’t execute JavaScript pieces that your code doesn’t originally produce, we might be tempted to refuse inputs including them. But this is a popular insecure practice that comes first to mind. Try to find an answer to the question of “what my code does to execute user provided JavaScript as code?”
Understanding the root of the bug will help you find the similar problems and the right mitigation techniques for them.
Find the right fix
It doesn’t make sense to have to do the wrong thing in order to do the right thing. J. DeMint
Follow the best practices in order to find right mitigation actions for fixing security bugs, although they seem awkward, uneasy and not clever at first sight (they might be called best practices for a reason). Along with other good resources, the OWASP has a good list of cheat sheets presenting the plausible fixes.
Of course after finding the fix, it’s important to create a good roadmap for implementing the chosen mitigation action and retest.
Search for similar bugs
The only source of knowledge is experience. A. Einstein
Up to now, the actions listed can be considered to be must for a good security bug fix process. However, there are more if you don’t want similar bugs to be a headache in the future. After all we all know the saying;
“…There’s an old saying in Tennessee — I know it’s in Texas, probably in Tennessee — that says, fool me once, shame on — shame on you. Fool me — you can’t get fooled again.”
or somewhere along these lines.
After understanding, finding the root and fixing a security bug, now we are the master of it. Then why don’t we look for similar bugs that the tests couldn’t catch, in the whole application? I can hear you say, “there’s no reason whatsoever! Let’s do it…”. Unless of course the fix you have produced is well protective that it prevents any future similar problems.
Generalize protection mechanisms
There is no ‘i’ in team but there is in win. M. Jordan
Once we know all the details about a security bug type, it’s now improve our team/enterprise knowledge about it. Almost all development methodologies promote generalization and highlight the importance of following coding best practices.
In agile development models (XP, Scrum, etc.), generalization means that everyone in the team should learn about the whole system as much as they can such as the basics of database design, coding, testing… This should also include the security knowledge.
Add a unit test
Test fast, fail fast, adjust fast. T. Peters
First of all, if we don’t use unit testing we should better start using. As we should produce a test case just right after writing a piece of code (or before if you are following Test Driven Development models), for a proactive security improvement, we should also add a unit test simulating the security bug you just fixed.
This will be an early alert for us catching the security bug if it gets on our way again, such as mistakenly disabling a whitelist input validation strategy before going production.
Conclusion
Following many actions in order to fix a simple bug might sound too much effort at first, but producing quality code also depend on quality bug fixing as it depends on quality coding. When we come across a security bug in our code, we may just go ahead, put an reliable input validation around a user input and declare that we are secure. Sure, that action may eradicate that instance of a security bug once and for all, however, the security bug itself may just be a preliminary signal of what’s ahead. In reality, we may have more issues just like this in our code and have to work a little harder to fix the root cause instead of saving the day.
Let’s don’t forget that these proactive mitigation actions for security bugs are also pretty similar to the process of fixing other non-security related software bugs.
