Month: April 2009

Book: Writing secure code

April 3, 2009

Have there been any inventions in human history which are as insecure as the softwares we use today? Just pull up the news in the last couple of weeks:

1. Google shares Docs without your permission: March 7, 2009 and again on March 26, 2009

2. Facebook reveals private photos on wall posts: March 20, 2009

3. Safari browser cracked in 2 seconds: March 18th, 2009

4. Cached data exposes 20,000 Credit cards: March 20, 2009

If you actually go through SANS list, you will be scared. And that is the world we live in today.


Writing Secure Code

An enormous number of softwares have been written, deployed, and exposed over the Internet in the last 10 years without enough thought on Security, and thus Security is going to be a huge huge thing for the next 10 years. After all, you have to clean up your own shit, right (unless you are a dog) ?

I started this book about a month ago, and I just finished it today. Written by Michael Howard and David LeBlanc from Microsoft, the book mostly talks in reference to C/C++, and the Dot Net framework. But unlike all other books that talked about Cryptography, secure protocols and algorithms, this book actually talks about writing secure code on a daily basis, and develops some principles for building secure software. In that sense, although a little old and a little too big, this book is an awesome read for someone wanting to write secure code. While Absolute Security is a Myth, at least you can make it difficult for attackers to exploit the vulnerabilities.

Every good developer is a hacker himself. So the book goes into details of Buffer overflows, Integer overflows, Cross-site Scripting, Sql Injections, Code Access Security, Using proper Access Control Lists, Cryptographic Techniques and its proper use, Encoding and Internationalization, Canonicalization etc.

The book argues that Security should be part of the design rather than an add-on at the end of coding. You should define your trusted and untrusted boundaries, analyze all the threats involved, and evaluate risks associated with the threats, and define your security goals based on the risk factor. All this should be a fairly short, simple and high level process, but it will tell the developer what you need to pay extra attention to and tell the QA what you need to watch out for. Through code review only, you can reduce your bugs by 80%, and most of the bugs found in code review will hardly ever be found through QA testing.

The most interesting side of the book is how it relates all the security problems to some breach of fundamental security principles. Just for my own reference, there are a quite a few security principles stated in the book that should be built into every developer’s subconsciousness:

1. Minimize the attack surface. (Think of hidden fields in forms)

2. All input is evil, unless proven otherwise. Also, assume all external systems you talk to are insecure. (Think whatever you want.)

3. Use principle of least privilege. Use elevated privilege only when you have to, and use it for the shortest amount of time possible.

4. Use defense in depth. Use OS level ACLs as the last line of defense.

5. Avoid security through obscurity. (Microsoft ?)

6. Security features != Secure features. Also don’t ever write your own encryption algorithms (unless ?).

7. Client-side security is an Oxymoron. Don’t try it (at work or otherwise).

All in all, this book has completely changed the way I used to look at my own code and systems, and has definitely made me a better developer and a thinker.

Now I see loopholes everywhere in my own code. Am I guaranteed to be safe from SQL Injection attacks just because I used parameterized query? Am I safe from Cross-site Scripting attacks just because I encoded the output? What if the attacker doesn’t use a browser? Did I canonicalize the filenames after the input? Although the language I use isn’t vulnerable to buffer overflows, am I safe from Integer overflows? What user is my application running as? What if somebody has already hacked into my system? While its not possible to chase after every theoretical bug within the code, we can at least prevent the ones that are obvious or extremely malicious.

But its businesses that build softwares, right? So here comes the million dollar question:

Is it possible to write highly secure softwares without costing extra money and substantial time for the company?

Answer: In general, at least most of the time, YES! Writing secure software is a habit more than anything else. However secure code is only a small piece of the puzzle, and cannot alone make the system secure if other basics are violated.