Book Review: Beginning ASP.NET Security

If you're doing web development with ASP.NET, you need this book. Simple as, end of.

And I'm not just saying that because I'm mentioned in it (page 235 for those of you playing along at home).

When I heard Barry was writing a book, I knew it'd be a good one to get, having seen Barry speak on security topics at several user groups and conferences. And now I've read it I can see it's going to become one of those books that never gets put away neatly on a shelf, it's always going to be open on someone's desk. Experienced developers shouldn't be put off by the 'Beginning ...' in the title, this book is for every ASP.NET/MVC/Silverlight/WCF developer who has security concerns. Which should be all of you.

The approach of the book is task-oriented; each chapter describes one or more vulnerabilities that a web developer may come across, and then describes how to mitigate against them. I started learning right from the first technical chapter, which covers validation: there are several things I've picked up about the ASP.NET validator controls, including how to validate input data against a .NET data type and how to write a custom validator. Cross-Site Request Forgery isn't quite what I thought it was either. Of course, things like Cross Site Scripting and SQL injection are covered, but also some of the more obscure vulnerabilities that are traps for the unwary; I'd never heard of things like traversal attacks and XPath injection. There is an excellent chapter on encryption covering all the options available in the .NET Framework for encypting and decrypting your data, although I'd have liked to see for each type of encryption some more suggested scenarios in which each method is appropriate. Coming right up-to-date Barry also covers how to use external authentication providers like OpenId, *ahem* LiveId and Windows Identity Foundation, and finally has a whole chapter on securing MVC applications, lest the lack of Viewstate and auto-encoding <%: tags leads MVC developers to believe there's nothing more they need to do.

Right, I'm off to do a security review of all our live sites. I may be some time...

Book Review: Code Complete

Back in April, inspired by John Robbins' blogpost about it, I promised I'd read Code Complete and review it here. I finished it last night (I confess I've read one or two other novels in between), but I can't believe it's taken me almost three months. Lest you think I'm some kind of slow reader, I will add at this point that there were also nights when I didn't read at all!
As soon as I finished it I felt like I should pick it up again and start from scratch - it's easy to see why people read it once a year. It's also easy to see why those who have read it suggest that everyone else should read it too - it's chock full (and I mean it's absolutely full at 862 pages plus bibliography and index) of tips, suggestions and methods to enable you to be a better developer.
I loved the checklist at the end of each section that you can apply to your development processes - these are also available (registration required) on the book's website though it's a slight disappointment that they aren't available as a Word or PDF download.

The message of the book is that creating high-quality software doesn't have to cost more and/or take longer than creating low-quality software, and it then lays out tools to help you do that.

It's nice to come across recommendation for things like coding styles and think 'I'm doing that already'. It's also good that the coding examples in the book are done in a variety of languages - I was fully expecting all the samples to be in C and therefore impenetrable to me, however they are done in a mix of C, Java and VB.

What didn't I like? McConnell talks in several places about programming into a language rather than programming in a language, and if I'm honest I'm not qure I entirely got what he means with this. And I found it a bit dry in places, but then I'd expect a book on software engineering written by Matthew Reilly (whose books are faster paced than anything else I've ever read) to be at least a little dry.

And I can already report some success traceable directly to Code Complete; I've tried laying out some code in a class using pseudocode that then forms the comments in the body of the code. And it is definitely a useful technique as I found it did make me think about the structure of the code before writing the code itself. So something to take forward there...

What's next for me? I may read it again in a few months - I suspect it's going to go round all our team first as I have two takers lined up already. In the interim, I have Professional ASP.NET MVC to read. I guess I should also read Writing Secure Code as I haven't read that either!