DANGER: UXC (Unexploded Code)!!!!!
Wednesday January 14th 2009Sloppy code. We’ve all seen it, and the problems it can cause. Whether that is not thinking things through fully (ie: no impact assesment), simply being careless and slapdash when it comes to writing code (ie: don’t care or in a rush to get it out), or even the programmer being as thick as two short planks (ie: should be digging holes for a living), the results can be pretty much the same.
I know one ‘programmer’ who doesn’t even compile code after writing it. They just hack it together, check it back in, and sit back with their feet up scoffing pies. Of course more often than not it wouldn’t actually compile, and it needed somebody else to fix their fix. Thus wasting everybody’s time.
Everyone makes mistakes of course. As the old idiom goes, “To err is human, to forgive divine” but to keep “err’ing” is just being slack (or stupid) and even forgiveness thins out at some point, especially when the the security and stability of both your application and the system it’s running on is at risk. But making a mistake and writing sloppy code are not the same thing at all.
A spelling mistake in a GUI isn’t going to allow the contents of your bank account to be transferred to the Taleban, but something as simple as not correctly validating user input could have a huge impact.
Not bothering to add proper input validation, or error trapping in an application isn’t a mistake, it’s often a conscious choice – often because people can’t be bothered; because of lack of knowledge; or because the coder is being pressured to get the job finished yesterday.
Everything is relative of course. If you’re writing an app that’s never likely to leave your hard drive that simply changes the meta data on an MP3 file, then you’re never going to bring about the end of civilisation, but if you’re writing web-based apps with a more serious purpose, you really do need to check your code. Really it should be a matter of course, and a habit you get into, ensuring any code you write is secure and should handle all known eventualities.
Good coding practices are things that should be taught (to programmers old and new), and followed as a matter of course. In this instance knowledge is power. The more you know about how sloppy coding can be used and abused the more secure and stable your application can be.
To this end The SANS Institute have published what they see as the top 25 most dangerous errors. All the usual suspects are in there: Improper input validation; Cleartext transfer of sensitive information; Hard-coded passwords (yes honestly!!), plus many many more.
I would suggest that the list is crucial reading for any self-respecting developer, even if at best they only use it as a checklist, or at worst as an eye-opener.
And if it is an eye-opener for you, then fear not, as they also have resources to help you eliminate the most common errors, in the form of some downloadable best practice guidelines. Download them, make yourself a brew and get your head into it. You won’t regret it.
You can checkout the full list at: http://www.sans.org/top25errors/