Writing Secure Software is Hard

All code is crap.  I know, because I've written a lot of it.  A long time ago, in a galaxy far far away, I wrote a large PHP based enterprise application that is still in production use today.  It's also being used as an example of how not to write code that will survive penetration testing.

Development of this application started in 1998, so in Internet years it is ancient.  A recent review of the application has found that XSS is possible in nearly every field, and while SQLI is harder to do that you'd expect, due to a protection framework I wrote to save me from writing bad SQL, it is still possible.

How can I have gone so far wrong?  The simple answer is I didn't know any better.

There are two foundation reasons why software developers don't write secure code.  The first is that they aren't told they have to, and the second is they aren't shown how to do it.  Both of these reasons applied to me - there was no specification for the application that included non-functional requirements such as security, and none of the university level courses I'd passed on software development even mentioned secure coding practices.  In my defence I'm going to throw in a third reason that these attack types were not well known at the time.

Unfortunately the foundations are just as weak today.  Most development projects don't include security in their requirements document, and most developers are not taught how to write secure code.  My third defence doesn't save us any more as the attack types are very well known.  Rapid prototyping methodologies just make this harder.

It's time to do it better.  All development projects need to have security as part of their project governance, and have developers trained by penetration testers on how their code will be abused.

Microsoft started in 2002 with their secure development initiative.  Most other large development companies have done the same thing.  But there are still a very large number of web facing applications being developed without the safety net of a secure software development lifecycle, and they will continue to fall over much to the surprise of their developers.

The 21st century has been around for a while now, but we're still writing code like it's 1999.

Phil Kernick Chief Technology Officer
@philkernick www.cqr.com