Test early, test often: 6 things you should know about application security testing

If you’re developing some applications in-house, and need to get them penetration tested before they go live, there are a few things you can do beforehand to help the process along a bit. I am not talking about specific bugs here, but rather changes to the development process to minimise the number of bugs in the code when it is released.

I should note that Microsoft have written at length about the Security Development Lifecycle, which I heartily recommend as a resource, but I’d prefer to give a two minute version here.

• Get your developers to read and think about at least the OWASP top ten issues: https://www.owasp.org/index.php/Top_10_2013-Top_10
• Put your code into a source code control system – I don’t mind if it’s github, or Visual Sourcesafe, as long as you have an audit trail of who did what and when. This will allow you to determine if a newly discovered bug is a regression, or if it has always been there, and it may show you who you need to train up a bit more in order to avoid such things in future.
• For any exposed interface, have a brief think about who has anything to gain by trying to subvert it, how they might go about doing so, and what the implications are for your product.
• Use a static code analysis tool to find basic errors. “YASCA” – Yet Another Static Code Analyser (http://www.scovetta.com/yasca.html) – is a reasonable start, and it might show up some errors you hadn’t thought about. “brakeman” does an adequate job for ruby. You should equally be aware that these tools will not pick up all your dangerous code.
• Perform peer code review, where one more senior developer should take a quick read through any code checked in by any other developer – especially for code written by junior developers.
• Us C programmers have always had the “assert()” macro, which is used to halt the program if an unanticipated condition occurs, that is to “fail safe”; unfortunately web development languages do not generally have this sort of flexibility – for many reasons – but it is always worth thinking about what would happen if your routine gets called with so-called “impossible” parameters.

Not doing these sorts of checks is almost as bad as going into an exam having barely revised, and not having looked at any past papers. You are liable to get nasty surprises during the first penetration test, which then may cause delays to your preferred release schedule. We would much rather spend one day talking to your developers when the project kicks off, than three days cataloguing and explaining errors and the fixes when the product is meant to go live a week Thursday.