Ajax Security by Billy Hoffman and Bryan Sullivan

I’ve had the manuscript of this book for about two weeks now. I approached this review from the point of view of having had a contract to write an Ajax security book myself, with No Starch Press. I actually approached Billy to see if he wanted to help write my book at Black Hat in 2006, but I never followed through… on either the book or chasing Billy down and getting on with the job. For those who wait, are those who do. Congrats to Billy in chasing down a publisher and getting a good co-author, and most of all – getting it done! Writing books is a hell on the social life, and I can’t imagine how many all-nighters they pulled to get this out the door.

So onto my mini-review.

The Good

Is it just a re-hash of old presentations? No. The book breaks some new ground, and fills in a lot of the blanks in all of our presentations and demos. I hadn’t heard of some of these attacks in book form before. The examples improved my knowledge of DOM and other injections considerably, so there’s something there for the advanced folks as well as the newbies.

I really liked the easy, laid back writing style. Must come from the laid back Atlanta-based authors (ps. I love it there). I don’t like it when authors write as if they are better than you by using big long words. Big long words just make my head hurt. Luckily, Billy and Bryan’s text is straightforward and easy to understand. They get across the concepts in a relatively new area of our field, coining at least a few terms (cross-site flashing, for example).

The structure flows pretty well, building upon what you’ve already learnt. They bring you up a little bit at a time. That’s not to say that there’s nothing here if you’re a Jeff Williams or a Jeremiah Grossman or RSnake – there is advanced stuff, but the authors have to bring the newbie audience along for the ride. I think they do this in a way that helps the newbie more than it helps the experienced folks – but that’s fine: the experienced folks are already au fait with much of the discussed techniques.

The bad

Well, there’s not much wrong with the book. I would have preferred more real live examples rather than “cheating” with Firebug, but that’s a small quibble. If you can do it with Firebug, you code will be pwned sooner or later.

Billy and Bryan spend a bit of time repeating the old hoary “no new attacks in Ajax” meme which is big with the popular kids (mainly because their products can’t detect or scan Ajax code yet and still want money from you), and then spend the rest of the book debunking their own propaganda with a wonderful panache that beats the meme into a bloody pulp and buries it for all time. Yes, there is a lot of old stuff that has crept back in, but honestly, Ajax is *different* in some areas, and it creates new attack surface by definition. There’s nothing really wrong with saying “hey, here’s JSON injection which is new” or “hey, here’s a hybrid Ajax CSRF attack worm, and that’s new”, “hey, you’re adding 25,000 lines to run in the untrusted browser, I reckon the attack surface is going to be bigger and more easily exploited”.

The book also fails to deal with framework authors in any major way. There are so many (bad) Ajax frameworks out there right now. You can accidentally create one if you scratch some code the wrong way. In my view, web application security can only be improved by targeting the frameworks (in the hundreds) rather than targeting the huddled millions who code for a living. However, the book will only sell in the tens of thousands if you target the poor bunnies cutting code. In my view, I would have liked it if the book had covered what *frameworks* should do. Maybe this could be fixed in the second edition.

The Ugly

The book concentrates far too much on attacks, and not enough on building and architecting secure Ajax applications. This is typical of the usual penetration tester mindset, which gets you the hot girls and invites to the swankest parties. However, it leaves a lot to be desired from the software engineering front. We have to stop treating security like a black art – it has to move to being the very way we code, so much so that it hurts if we do it the bad old way. However, penetration testing is far sexier that software engineering, and I’m sure this will not hamper sales in any way (c.f. Hacking Exposed, etc).

Conclusion

If you are writing or reviewing Ajax code, you need this book. Billy and Bryan have done a stellar job in a nascent area of our field, and deserve success. Go buy this book. I can’t wait for it to come out.

7 Replies to “Ajax Security by Billy Hoffman and Bryan Sullivan”

  1. When did the word “architect” become a verb? Why don’t you just write “building and designing”?

    [Note: the “you” in the previous sentence directed at anyone who thinks architect is a verb. As Calvin once said, in a strip on verbing (sic) words, “Perhaps one day we can make language a complete impediment to understanding”. Or maybe it was Hobbes who said that. Either way, it was definitely Bill Watterson. I’ve half a bottle of red inside me, and well on the way to becoming truly sloshed.]

  2. Because I love verbing words. In particular, “to architect” is actually a very common usage. I hear it all the time at conferences. Languages change and move around. This is one of those times.

    Andrew

  3. It’s ironic that architects (the profession noun) chose not to verb their title: they use the cleaner “to design”. What is the difference (in an IT context) of “to architect” and “to design”?

    I agree that langugaes change over time. That’s not to say that changes should be accepted uncritically; some changes distort clarity and meaning. This is a common tool-in-trade of politicians (see Orwell, 1947, for his doubleminusbad book). Why, I remember when those contractors in Iraq used to be called mercenaries. Hell, I even remember when Ajax was a cleaning product rather than a framework.

    My belief is that this use of architect as a verb is to be discouraged, unless someone is able to point out a genuine distinction between “to achitect” and “to design”.

    The Wing Commander

  4. Paul,

    it is too late. Architect has several meanings in the larger and more prestigious dictionaries, and it is in common use in the IT industry (and others). There is a real distinction in most of the large corporations I’ve worked in:

    Business Planning
    Requirements Analysis
    Architecture – the bit that will not change in the lifetime of the project
    Design – the mechanicals of how this particular incarnation will implement the architecture. Can change over time and be re-factored, but will be true to the architecture
    Build
    Test
    Deploy
    Rinse and repeat

  5. Hey Noddy,

    Fair points on the use of architect in a broader sense than which it was originally known.

    My issue (which I don’t think you’ve addressed above) is the use of architect as a verb. Other than one weird online dictionary, I’ve yet to find any source with “dictionary” in the title which recognizes “architect” as a verb (either transitive or intransitive).

    Your list above looks similar (different scale) to most projects in large enterprise space I’ve worked on too…

    Cheers,
    The Wing Commander

Leave a Reply

Your email address will not be published. Required fields are marked *