Recently in Software engineering Category

Writing code is easy, writing good code is hard

Every now and then, I dabble in coding. Every time I develop software, I realize that writing code that does what it supposed to do is not all that hard. However, writing code that does exactly what it supposed to do, and only what it is supposed to do, is incredibly hard.

Automated application testing is a very valuable tool. Systematic and complete checking of all inputs and outputs is something that is incredibly tedious, labor intensive, and as a result, takes a lot of time and patience. That also makes it a very expensive process to do manually.

Good tools are available to test each input element and each output element of a web application, and their use should be far more wide-spread than it is now.

Web application security is about much more though; it involves session handling, authentication and authorization, access control, cookie theft, replay attacks, URL manipulation, intrusion detection (and prevention), etc., etc. Good people who understand these issues in-depth are rare and deserve all the credits that one may give them.

In addition to using automated tools to test the application, peer-review of code is a good thing and it may catch ugly solutions or design flaws. Using "eyes on lines" it becomes much easier to catch backdoors, or other code vulnerabilities that might not be obvious to find using automated tools.

All in all, we need to do much more quality control on code before it gets released. Automated testing tools must be run before code gets released and careful peer-review of code should be embedded in the full software development cycle.

Confirmation bias

| No Comments | No TrackBacks

Robert Graham over at Errata Security has a very interesting post up. The topic of the post is confirmation bias, a well-known concept in science that revolves around the idea that a theory is only valid when you can not disprove it (rather than when you can prove it).

"Because of this, the first time somebody misconfigures BitTorrent to use too many connections, the router crashes. Likewise, internal processes within the router crash often and silently restarting without being visible from the outside - but still passes QA tests because they aren't looking for that. Anything unusual that the user does is likely to cause a crash."

Definitely an interesting read.

Happy Monday.

Code review can only do so much...

I am involved in the development of the Application for Incident Response Teams (AIRT). AIRT is GNU GPL-licensed Free and Open Source Software that is designed to do one very specific task very well: to support computer security incident response teams (CSIRTs) in the bureaucratic aspects of incident response.

AIRT allows CSIRTs to receive incident reports, extract the relevant information from them, create incident tickets, follow the process flow of handling the tickets, and communicate with the teams that are handling the incidents, or track incident handlers. A lot of AIRT's development is directly influenced by SURFcert, the Dutch National Research and Education Network's CSIRT.

Those who have ever designed an information system or an information architecture should really read this article by Shae Allen.

The post is so well written and accurate that it is almost scary.

Thanks to Paramu of The Bleeding Edge who linked to the article.