Category: Books

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_code1

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.

Coding Slave

June 13, 2008

Everyone writes about codes. There are not much books on “Coders”. Ever since I heard about the book Coding Slave from a number of bloggers, I always wanted to read this book. But I was kinda scared that this one might be too venomous and negative, making everybody other than coders look like a villain. I finally grabbed the book and completed it after two nights of reading.

To summarize in short, it’s a story about an enterprise software development team within a typical corporate world of today. This book is about firing and hiring, off-shoring and consulting, project plans and deadlines, BA’s and QA’s all under managers trying to climb up the corporate ladders. If you have ever worked as a developer in a large financial institution working on huge ERP systems that never get completed, this book will resonate with you better.

If I consider this book as a piece of literature like any other books, I have to admit that this book is the worst I have ever read in terms of its presentation, quality of expression and character buildup. But I am assuming its from someone who knows a dirty side of the present IT industry too well, and he is not necessarily a good writer. There is an offensive amount of ’sex’ involved, strip clubs and cam girls, death and suicide. I am not exactly sure why the writer decided to stuff so much of unrealistic sex into the story, but I guess that writer is really clever in knowing who his reader is going to be; a slightly pervert and a geek that is.

IT industry esp. the IT departments within companies are usually under wrong hands. Its always ‘get the code out fast”, and make sure “it sort of works”. Its just about meeting deadline; its just about media coverage, shares and profits. Nobody really cares about customers of the software. A project manager never gets fired for a unrealistic deadline or a bad project plan or hiring a wrong person in a team. But a developer who has produced years of great code in the same team gets fired one day coz he couldn’t follow a bad project plan and meet the deadline. A BA seldom gets fired for misinterpreting a customer’s voice in the project requirements. But if a project fails to meet a deadline, everyone looks eyes crossed at the developer. BA’s come with last minute changes, saying that it’s a minor functionality change. But nobody really understands that what they think is a minor change needs a major code refactoring from the developer. Result? Another late night or a spoilt weekend! After all having worked so sincerely all the way through, you don’t want your manager to give you that shitty “Its all your fault” look at the 9:00 AM project status meeting every morning.

All in all, we are coding slaves. We work under some kind of dictatorship to build the software. We get victimized for everything that fails (be it our fault or not), and someone else gets the kudos and promotion for the success. This is the reality of majority of software development teams.

The author thinks we - coders ourselves are responsible for the mess. We let the people who know nothing about software run the show. No surprise that he doesn’t want you to do the unit tests, documentation or re-factoring, coz it all makes our lives easier and not his. We aren’t enslaved by the corporation or the system, but its our own attitude thats enslaving us. We are the only people who knows the software well, and who are passionate about it like a mother to a child. We care for its well-being and health. We care for its usability and quality, and have the right skills to nurture it. The author finally envisions a philosophy where the developers control and manage all this. We should be the masters of the software, not someone’s coding slaves!!

I think the open source community of today is kind of close to what the author has dreamt. Open source projects are driven by coders, driven by passion, driven by a reason, skill, knowledge and thats why they have been so successful. There isn’t a non technical boss (who knows nothing about software) telling the coders how they should build the software, what it should be like, and when it should be checked into the repository.

The industry is not short of places where good developers are forced to write dull and boring codes.