It recently came to my attention that there are some gaps in my conceptualization of Drupal security. I was fortunate enough to have this pointed out to me by the Drupal Security Team, and not by a DOS, CSFR, SQL injection or XSS attack. After publicly bemoaning the mild lashing I received, four members of the Drupal community suggested I read Cracking Drupal. One of them even sent me a copy. No other book was even mentioned, which says to me that - considering how recently it was released - the book fills a void of knowledge that was seriously aching for coverage, and fills it well.
Over years of developing, I've become familiar with the various vulnerabilities that make their way into code, but I've never felt like I could build a complete defense. My knowledge has been piecemeal, drawing from documentation, books, interesting conversations and other people's code. In my case, Cracking Drupal did a fantastic job of gluing these pieces together into a comprehensive frame of mind.
What becomes clear very quickly in Cracking Drupal is that Drupal is quite a wily beast that gives developers real incentive to learn security. There are few functions in Drupal whose exclusive purpose is security, and Greg makes it clear that learning how to secure your site has definite side benefits: "When developers learn and use the API, they are not only safer but more effective and more efﬁcient." When you learn how to use different aspects of the Drupal API (forms, translations, helper functions, theming) you gain bits of security as a bonus. If you set out to learn Drupal security, you'll come out the other end with a pretty solid grasp of Drupal APIs. Either way, it's a win.
Cracking Drupal is surprisingly brief. In 134 pages, Greg covers a lot of ground including:
- An overview of the different types of attacks one is likely to encounter, from physical to social
- Most (if not all) aspects of the Drupal API that have security implications
- Coverage of security-related contributed modules
- An introduction to the Drupal Security Team
- Demonstrations of exploiting common weaknesses in Drupal modules and how to fix them
An interesting choice is made in Cracking Drupal to keep a somber atmosphere around the subject matter. In almost any other context, this would be an immediate turn-off. I appreciate humor and optimism to drive my enthusiasm when reading. In contrast with other instructional books which end a chapter with a "go for it, get things done!" message, this book ends chapters with lines like "This paranoid perspective is a good one to maintain as you write, review, and implement features on your site." and "Remember that it is nearly impossible to fully protect yourself from a dedicated and persistent attack." and "If nothing else, I hope this chapter has scared you a bit about the realities of just how easy it is to exploit insecure code and sites".
In a book covering attacks that can result in a very serious loss of time and money, this lack of optimism is probably a good thing. And the final chapter, "Un-cracking Drupal" does leave the reader with the sense that something can be done. It's difficult work, but it's doable. Ultimately, I think the book drives home the fact that the most effective way to make a module or theme secure is to do it right from the start.
The title chapter of Cracking Drupal was probably the most lively and hands-on part of the book. I came out of it feeling like I could really enjoy exploiting vulnerabilities for the greater good. Because of this reaction, I think it would have been a good candidate for a first chapter to really whet people's appetites.
Overall, I think Cracking Drupal does a tremendous service to the community by pulling together the most important aspects of Drupal Security into one solid, compact document. While I came into the book having already been introduced to many of the concepts, it filled in a few gaps, and made the subject matter finite and approachable (albeit a little scary). I suspect this book will serve well as a guide and quick reference as I dive into identifying and patching up vulnerabilities in the modules I maintain.
A couple things I learned
While the greatest benefit to this book was the broad, sweeping overview of security, there were a few additional gems that will come in handy later on:
- There's a lot more to hook_menu() than I was aware of. Good coverage of examples on p.55
- I didn't realize that you had to exit after using drupal_access_denied(). p.59
- Ah, db_placeholders() - a useful function for passing a number of variables to db_query() p.65
- I had no idea there was such a robust node access API. Wow!
Notes in the margin
Below are a few unorganized comments that constitute my wish-list for future versions and complements to the author:
- Good quote regarding the definition of security: "For this book I’ll deﬁne site security as follows: A site is secure if private data is kept private, the site cannot be forced ofﬂine or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users."
- I would have liked to see more AJAX security strategies and techniques covered.
- I liked all the Drupal 7 references, gives a good feel as to the direction of things
- I was surprised that there were not more brutal admonitions about hacking core, but suspect that's because they represent much fewer vulnerabilities than badly designed contrib.
- I was happy to see some coverage of CVS and DRUSH, namely using CVS to keep code up-to-date
- Nice coverage of security-related modules starting around p.41
- A brief mention is made that using mixed-mode SSL is pretty pointless. This is a big deal, I wish it had gotten further coverage.
- Being more of an optimist, I appreciated this particular phrase: " Every day there are more and more techniques beingdeveloped to attack sites, but every day there are also Drupal users reviewing code and providing new modules and enhancements to core to keep your site safe." Ahh, a glimmer of hope!
- Would have liked to see more coverage on the use of form tokens. If one must step outside of the forms api, this could be very important
- I liked that theme safety was covered, and thought the take on it was interesting: Make the theme secure by giving themers no reason to make stupid mistakes.
- Since the 'Vulnerable' module was patched up in the end, maybe it should actually be named to indicate that it's meant to be a useful module. That would feel more like a practical example.