Once in awhile 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
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 not follow this process many times, as you grasp the details of each different types of security bugs (unless the code you work on sucks, security wise that is...).
Find the root of the bug
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.
Most importantly, understanding the root of the bug will help you find the similar problems and the right mitigation techniques for them.
Find the right fix
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
Up to now, the actions listed can be considered to be musts 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 know what they say;
“...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 something like this.
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
Once we know all the details about a security bug type, it’s now time to improve our team/enterprise knowledge about it. Almost all development methodologies promote generalization and highlight the importance of following coding 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
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.
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. Let’s don’t forget that these proactive mitigation actions for security bugs is also pretty similar to the other software bugs.