Cracking Drupal E-Book

Greg Knaddison

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 290

Veröffentlichungsjahr: 2011

Beschreibung

The first book to reveal the vulnerabilities and security issues that exist in the sites that have been built with Drupal?and how to prevent them from continuing Drupal is an open source framework and content management system that allows users to create and organize content, customize presentation, automate tasks, and manage site visitors and contributors. Authored by a Drupal expert, this is the first book to reveal the vulnerabilities and security issues that exist in the sites that have been built with Drupal?and how to prevent them from continuing. The main goal of this guide is to explain how to write code that avoids an attack in the Drupal environment, while also addressing how to proceed if vulnerability has been spotted and then regain control of security.

Leseprobe

Table of Contents

Titlepage

Copyright

Dedication

About the Author

Credits

Acknowledgments

Introduction

Who Should Read This Book?

Who Am I? Why Did I Write This Book?

What This Book Covers

Parts of the Book

What Is Needed for This Book

Book Conventions

Part I: Anatomy of Vulnerabilities

Chapter 1: That Horrible Sinking Feeling

Avoiding That Sinking Feeling

Common Ways Drupal Gets Cracked

The Big Scary World

The Most Common Vulnerabilities

Summary

Chapter 2: Security Principles and Vulnerabilities outside Drupal

Server and Network Vulnerabilities

Social and Physical Vulnerabilities

Summary

Part II: Protecting against Vulnerabilities

Chapter 3: Protecting Your Site with Configuration

Stay Current with Code Updates

Know Your Attack Surface

Using Extra Security Modules

Smart Configuration of Core

Summary

Chapter 4: Drupal's User and Permissions System

Using the API

What Are Hooks, Form Handlers, and Overrides?

Defining Permissions: hook_perm

Checking Permission: user_access and Friends

Common Mistakes with Users and Permissions

Summary

Chapter 5: Dangerous Input, Cleaning Output

Database Sanitizing: db_query and Friends

Translation and Sanitizing: t

Improper Use of t

Linking to Content: l and url

The Form API

Filtering Content: check_plain, check_markup, filter_xss_admin

Summary

Chapter 6: Safety in the Theme

Quick Introduction to Theming in Drupal

Common Mistakes

Summary

Chapter 7: The Drupal Access System

Respecting the Access System

Summary

Chapter 8: Automated Security Testing

Test Drupal with Drupal: Coder Module

Testing Drupal with Grendel-Scan

Summary

Part III: Protecting against Vulnerabilities

Chapter 9: Finding, Exploiting, and Avoiding Vulnerabilities

Strategies to Crack Drupal

Searching Core and Contrib for Vulnerabilities

How to Report Vulnerabilities

Summary

Chapter 10: Un-Cracking Drupal

Step 1: Secure the Menu

Step 2: Secure the User Search

Step 3: Secure the Node List

Step 4: Disable Users Safely

Drupal Un-cracked

Part IV: Appendixes

Appendix A: Function Reference

Text-Filtering Functions

Link and URL Building Functions

Users and Permissions

Database Interaction

Appendix B: Installing and Using Drupal 6 Fresh out of the Box

Step 1: Installing Drupal—Easier Than Ever Before

Step 2: Designing and Building the Architecture

Step 3: Creating the Business Objects

Step 4: Creating the Workflows

Summary

Appendix C: Leveraging Community Resources

Resources from the Drupal Security Team

General Security Resources

Summary

Glossary

Drupal-Specific Jargon

Index

Cracking Drupal®: A Drop in the Bucket

Published by

Wiley Publishing, Inc.

10475 Crosspoint Boulevard

Indianapolis, IN 46256

www.wiley.com

Copyright © 2009 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN:978-0-470-42903-7

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone]. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read.

Library of Congress Cataloging-in-Publication Data

Knaddison, Greg.

Cracking Drupal : a drop in the bucket / Greg Knaddison.

p. cm.

Includes index.

ISBN 978-0-470-42903-7 (pbk.)

1. Drupal (Computer file) 2. Web sites–Security measures. I. Title.

TK5105.8885.D78K63 2009

006.7’6–dc22

2009007449

For general information on our other products and services please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Drupal is a registered trademark of Dries Buytaert. All other trademarks are the property of their respective owners. Wiley Publishing, Inc. is not associated with any product or vendor mentioned in this book.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

To my life partner, Nikki. You are the smartest, sweetest person I could ever have the good fortune of marrying, and you make me laugh more now than I could have ever hoped. I love you. Dearly.

About the Author

Greg James Knaddison is a dedicated Drupalista. For nearly four years he has volunteered with the project in a variety of capacities. From his involvement with the drupal.org site teams—documentation, site maintainers, infrastructure, groups.drupal.org maintainers, project maintainers, security team—to his work on several contributed modules, to his mentorship in Google Summer of Code, to founding and organizing the Drupal Denver/Boulder User Group, to the development news site DrupalDashboard.com, to his role as a Community Ambassador of the Drupal Association, Greg is involved with Drupal in almost every way he can be. And he has a job working with Drupal sites all day. Often those sites are related to publishing—either print media publishers or purely digital sites. When not working with Drupal, Greg likes to go mountain biking with his life partner and read fine publications like The Economist. You can get all the code for this book as well as all the latest updates by visiting his site, http://crackingdrupal.com.

Credits

Executive Editor

Carol Long

Development Editor

Maureen Spears

Technical Editor

Károly Négyesi

Production Editor

Melissa Lopez

Copy Editor

Linda Recktenwald

Editorial Manager

Mary Beth Wakefield

Production Manager

Tim Tate

Vice President and Executive Group Publisher

Richard Swadley

Vice President and Executive Publisher

Barry Pruett

Associate Publisher

Jim Minatel

Project Coordinator, Cover

Lynsey Stanford

Proofreader

Corina Copp, Word One

Indexer

Robert Swanson

Cover Designer

Michael E. Trent

Acknowledgments

The Drupal project leader Dries Buytaert deserves my utmost thanks—not just for his work on the project but for his amazingly caring and humble nature, which made me feel like a valued member of the community from my first handbook edit. Károly Négyesi (chx), was technical editor for this book, keeping all my examples solid, and he has been an amazing mentor to me in general. Numerous individuals provided ideas and feedback as I wrote this book: Heine Deelstra, Khalid Baheyeldin, Brad Bowman, Crell Garfield, Dario Battista Ghilardi, Ezra Barnett Gildesgame, Steve Harley, Emma Hogbin, Mike Hostetler, Ben Jeavons, Gerhard Killesreiter, Earl Miles, Joon Park, Stella Power, Derek Wright, and Peter Wolanin stand out, among many others.

Jim Carpenter, the best professor I've had, taught me to have fun with computers and business. Laura Ordway taught me to be a curious and independent person and to enjoy my environment. More personally, my friends, parents, and extended family members have provided invaluable encouragement throughout the process of the book.

I'm indebted to you all, and only some of you will be satisfied with a signed copy of the book. To the rest…can I buy you a beer?

Introduction

I hope you've purchased this book before having a security problem rather than after. As I relate in Chapter 1, being the target of an attack is not a fun situation. Especially online, attacks can be painful: The stakes are often surprisingly high. Attackers can ruin images and text that took months to create, blemish your reputation as a reliable site, and steal users' private information; the result of nearly all of these problems is ultimately the loss of money.

You got into Drupal because it helps save time and money: It's a powerful tool available for free that anyone can use to build great sites (although, of course, there is the chance that you got into Drupal because your boss told you to!). Does the danger of an attack mean that using Drupal will be worse than using a homegrown solution? Fortunately, the answer is no. By default, Drupal provides great security protection and has an API that makes it easier for developers to avoid and eliminate security problems.

Who Should Read This Book?

This book was written with three major audiences in mind: Drupal site admins, professional developers/themers, and IT sysadmins/security generalists. Hopefully you identify with one of these three groups.

Drupal Site Admin

Perhaps the biggest group of people who will benefit from reading this book is Drupal site admins. These are people who have a site or a few sites that they maintain. They may know how to do a little bit of HTML, CSS, and/or PHP but are really more comfortable using Drupal's administrative interface than writing code. Does that sound like you? If so, you need this book because it will help you understand web application security and help you know which Drupal modules you could use to protect your site. Also, you'll learn enough about safe coding to be able to read a module or theme and see where the mistakes are.

This book covers some advanced programming topics, which means you've got a great book in your hands: In addition to learning security, you'll get a free introduction to the Drupal API. If you need help getting a Drupal site installed, see Appendix B, which includes a complete guide, from installation to building a multilingual site. From another perspective, some of the examples may feel a bit beyond your skill level. If you ever feel that way, you can, of course, try rereading the example, but you can also reach out to the community for more advice. The book provides several lists of resources showing where you can get more help.

Professional Developer or Themer?

Drupal's community is famous for being a group of hardcore techies, so certainly a large number of people reading this book will be developers and themers who write the code that runs the site. Maybe you maintain several projects on drupal.org as well. This book will help you to recognize security issues and use the Drupal API properly to protect your code against those issues. You'll also learn about the best modules you can use to protect your websites or, more likely, your customer's websites.

This book should be right at your level. Some of the examples may cover things you already know, but there's a good chance that the explanations will enhance your knowledge of the subject. Of course, there is the slightest chance that some of the topics will be too advanced for you. Again, please refer to the online resources (Appendix C) to get additional help.

IT, Sysadmin, Security Expert

It's possible that you're one of the many people whose “normal job” has nothing to do with Drupal but everything to do with providing technical support for the business needs of an organization. Maybe you're typically a system administrator, a member of a company's security team, or part of the IT support staff. I imagine you got this book because you've been told you need to roll out a Drupal site, and you want to understand the implications for the overall security of your organization.

Much like the Drupal site admin user, this book will give you a free introduction to Drupal, complete with how to install a site and some glimpses of how to write code for Drupal. If you have no experience with PHP, then you may struggle some with the examples. However, PHP is meant to be easy to learn and is very similar to other programming languages you may know.

Who Am I? Why Did I Write This Book?

I started using Drupal in the summer of 2005. My community needed a new website to share information about our meetings, and I wanted to make it a site where everyone could add information. A year and a half later, I was enmeshed in the community wherever I could be. I was addicted to helping make the Drupal software better, and I enjoyed learning about new technologies and issues related to web development. After posting a security-related item on my blog and stepping in to help out with a vulnerability in the Pathauto module, I was invited to join the security team.

At first, my role on the team was largely related to administrative tasks: helping track issues reported to the team, coordinating efforts by contributed module maintainers, and confirming bugs reported to the team or patches that would potentially be used to fix bugs. Over time I learned to recognize security weaknesses in Drupal modules and found a few weaknesses.

In 2007 at Drupalcon Barcelona, the security team was feeling particularly overwhelmed. We decided that we could not simply be reactive and fix bugs as they were reported. There were simply too many bug reports coming in for us to sustainably handle the problems. So we set about on two proactive courses:

To improve the API so that it more consistently protects users by defaultTo educate our community on how to write secure code so that the modules available on drupal.org would be more likely to be safe from the beginning

I worked primarily on updating and writing documentation and spreading knowledge about security at conferences and meetings.

In 2008, I was approached by Wiley to write this book and of course leapt at the opportunity. While the documentation on drupal.org is of high quality, a single person assisted by multiple editors in assembling a comprehensive, coherent book can produce a better outcome (being paid to do that work helps, too!).

What This Book Covers

By reading this book, you will learn about the most important security issues facing a Drupal 6 website. This field doesn't drastically differ much from one version of Drupal to the next, and I've taken time to provide extra detail around some of the changes that came from Drupal 5 and are likely to be included in Drupal 7 (Drupal 7 is about halfway down the path to being released as the book goes to print).

In particular, the book discusses how to avoid the most common vulnerabilities in Drupal. The specific classes of vulnerabilities are based on the most common problems reported in announcements from the Drupal security team and my personal experience with code and configuration issues witnessed over nearly four years of involvement with the project.

Parts of the Book

This book is designed to be read from cover to cover. If you are already a web application security professional and simply need to know how to protect Drupal, then you can skim the first chapters of the book.

Part I: Anatomy of Vulnerabilities

Part I shows you the most common vulnerabilities that you will face. In order to protect against attacks, you first have to understand how the attack is carried out and what impact it can have. You also learn a few items that are explicitly not covered by this book. Part of security is knowing what you don't know.

Part II: Protecting against Vulnerabilities

In Part II you learn the various methods to protect your site from these common vulnerabilities. Starting with your site configuration, you see how a single small, bad choice by an administrator can make a site totally vulnerable. Next you will review some of the Drupal APIs for permissions, output filtering, and content access. The section finishes with some best practices in server access and maintenance. Drupal is only as safe as the underlying server.

Part III: Weaknesses in the Wild

Part III reviews weaknesses in their natural state: the wilds of the Internet. You start by reviewing some methods for finding vulnerabilities and figuring out how to exploit a vulnerability. Then you head straight to the bug-reporting and -fixing process so you can help make Drupal safer.

Part IV: Appendixes

This is bonus material that includes a function reference and a glossary of terms. Also, author and Drupal expert Victor Kane provides you with step-by-step instructions on installing Drupal 6 and using it to create a multilingual site.

What Is Needed for This Book

This book is written to be valuable if read in isolation, but you are likely to learn more and understand the problems better if you have a few tools at hand to explore along with the book. From most important to least important, you should have these tools available:

Drupal version 6.x, though 5.x and 7.x may be more appropriate depending on the version you use on your server.The software stack to run Drupal, most commonly Apache, MySQL, and PHP. See Appendix B for more details on installing these. Since this book uses an example module that creates vulnerabilities in your site, you should be set up to run Drupal on a system that is separated from the Internet at large, such as a laptop or server inside a private network and with its own firewall.A text editor or integrated development environment (IDE) to be able to view and edit code files. If you need a basic editor, jEdit is a nice choice, while Eclipse PDT provides a good IDE. See

http://www.jedit.org and

http://www.eclipse.org/pdt for downloads.

Command-line applications like ls, grep, and cvs. These are often included by default on Linux and Mac OS X and are also available via tools like Cygwin

http://www.cygwin.com.

Some chapters may require additional software—Chapter 8 in particular uses the separate Grendel-Scan, which relies on Java 1.6 + —but it is less important than these fundamental pieces of software.

Book Conventions

To help you get the most from the text and keep track of what's happening, we've used a number of conventions throughout the book.

Warning

Boxes like this one hold important, not-to-be forgotten information that is directly relevant to the surrounding text.

Note

Notes, tips, hints, tricks, and asides to the current discussion are offset and styled like this.

This is a Sidebar

You may occasionally see sidebars, which contain useful tips and asides to the main discussion.

As for styles in the text:

We italicize new terms and important words when we introduce them.We show keyboard strokes like this: Ctrl + A.We show filenames, URLs, and code within the text like so: persistence.properties.We present code in this manner:

We use a monofont type to indicate a code line or block.

Part I

Anatomy of Vulnerabilities

In This Part

Chapter 1: That Horrible Sinking Feeling

Chapter 2: Security Principles and Vulnerabilities outside Drupal

Chapter 1

That Horrible Sinking Feeling

Insight into web application security and why you should care about it

I remember it quite clearly. I woke up, stumbled to the coffeemaker to start a brew, went back to my computer to look for updates on the phpBB message board to chat with some friends, and was panicked by what I saw: My home page had been replaced by a message from the “SantyWorm” that looked something like Figure 1.1.

Figure 1.1 Imagine if your website were replaced with this.

My heart began to race, and I worried about what might have happened and how I might fix it. I poked around the administrator pages of the site, but every way that I tried to fix it was met with the “hax0rs lab” message mocking me. Then, defeated, I slumped over in my chair, hung my head, and exhaled deeply. All I wanted was a forum to talk with my friends. I'd never considered that I would need to update that software from time to time. I was naïve.

Avoiding That Sinking Feeling

If you've had that experience, you know it's not a good one. The best-case scenario is the one that I was in—I had a recent backup of both the files and the database. I used a web-server-level password to lock out access from everyone but me, deleted everything, restored the backup, upgraded my site to the latest version of phpBB, and then let visitors back into the site. The worst-case scenario—well that's hard to imagine.

What is the worst-case scenario if your site gets attacked and the security is broken? Perhaps the usernames, passwords, and emails get stolen from the site, which could then ultimately allow the attacker to log in to your bank and take your money. Perhaps your site becomes a spam relay or a download source for malware, infecting thousands of computers. Or perhaps your site guards valuable proprietary information about your company, which the attacker can copy without your knowledge. As Kevin Mitnick wrote in his book The Art of Deception (Wiley Publishing, 2003), “When you steal money or goods, somebody will notice it's gone. When you steal information, most of the time no one will notice because the information is still in their possession.”

My goal with this book is to reach out to people who are naïve about how to keep a Drupal site secure. Perhaps you're not as inexperienced as I was—why did I think that I wouldn't need to update the software!—but there is a lot of information you will need to know to keep your Drupal site secure. To some extent you can simply follow the security updates closely, and that's all you need to know. Then you would rely on the other users of Drupal to make sure the software is secure. But…should you trust them?

It's Up to You

Sadly, the reality is that you cannot simply rely on other Drupal users to keep the code safe. A surprising number of websites are configured insecurely. A similarly surprising number of contributed or custom modules and themes contain logical or programmatic vulnerabilities. You must pay attention if you are going to keep your site safe.

When you have finished reading this book, you will know what steps you should take to protect a basic Drupal site, how to review a module to find weaknesses and how to fix them, and what extra steps you can take to protect your site if you need additional protection.

What Is Web Application Security?

I don't want to get totally philosophical on you, but I do spend some time with some deep thinkers up in Boulder. There are several aspects that most people include in the concept of website security. Generally, a site is secure if it is safe from danger or loss. For this book I'll define site security as follows: A site is secure if private data is kept private, the site cannot be forced offline 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.

Keeping your site secure by that definition should be simple, and yet there are dozens of methods to violate a part of the rule of security, and hundreds of examples of vulnerabilities within the Drupal project have been revealed over the last few years. So what can we do?

Security Is a Balance

You may already be feeling overwhelmed. To be perfectly safe requires so much work—how can anyone do it? The fact is that a typical site shouldn't implement every security recommendation in this book. Running a site is always a balance between what is practical, reasonable, and necessary.

Most security best practices have trade-offs from somewhere else. Sure, it would make your site instantly safer to use an SSL certificate for every visitor to every page, but that adds additional load on the server and additional cost to you. Or if you use a self-signed certificate, it adds additional work for your site visitors in order for it to work.

As the site administrator you must understand potential security weaknesses, your users, the priorities for your site, and your budget, and you must balance them all. Hopefully you already know your budget and the priorities for your site. Your users will probably let you know if a new security process annoys them too much. It's my job to explain the weaknesses and solutions so you can decide whether to implement them. On the other hand, many of the recommendations are absolutes. There simply is no reason to leave an SQL injection vulnerability in your site.

Common Ways Drupal Gets Cracked

This section is a review of some of the most common vulnerabilities found in Drupal.

The Drupal API provides protection against most of these common security vulnerabilities, but in order for that protection to work, themers and module developers must actually use that API. Unfortunately it is often the case that new developers to Drupal are unaware of how to properly use the API.

Vulnerabilities within the code of a site are the biggest category of weaknesses. However, as you'll see in Chapter 2, they are only one kind of potential weakness in your site.

This chapter introduces the Vulnerable module. Drupal's functionality can be extended with the use of modules. Modules are a common source of security weaknesses on sites. You can download the Vulnerable module from http://crackingdrupal.com/content/drupal-vulnerable-module.

Note

This URL is formatted with the full http:// on the front of it because you are expected to actually visit it. Either example.com or the short-hand notation for a URL that shows just the information after the Drupal root is used throughout the rest of the book for URLs that are important less for their content than how the data is used in the URL. For example, the URL for the login page in an example can be expressed either as http://example.com/user or simply /user.

The purpose of the Vulnerable module is to provide easy-to-understand examples of the different vulnerabilities covered in this book and how to fix them. These examples are fake, but the vulnerabilities they represent are real, and you only have to look at past security announcements to see real-world examples of the flaws. This module is useful as an example for the book and for your own study, but it should never be installed on a real site.

Note

The entire set of vulnerabilities attackers use is enormous and growing all the time. Covering all of them would be a waste of your time. Instead, this book covers just the most common and most important vulnerabilities so that you can focus on what really matters.

Authentication, Authorization, and Sessions

The three interrelated concepts of authentication, authorization, and sessions govern users and permissions. Together, they form a key part of a site's attack surface, because vulnerability here allows the attacker to pretend to be another user on the site or do something that's not allowed. In a system like Drupal, where the administration interface is merged with the regular interface, this area is even more critical. Finding a weakness here may allow an attacker to assume the role of an administrative user or view private content.

Note

The attack surface of a site is like a map of the ways to crack into the site. Certain parts of the attack surface are more likely to yield valuable results.

Authentication: Prove Your Identity

When you go to a bank and withdraw money from your account, the bank has security processes to make sure that you are really the person who has the permission to take this action. If you use an ATM, your ATM card and PIN act as proof of your identity. If you go to an agent of the bank, your driver's license or passport may be your proof. Similarly, different websites use various mechanisms to prove your identity.

By default Drupal uses the common username and password combination to authenticate users (see Figure 1.2). Numerous other contributed modules can be used to enable alternate authentication mechanisms.

Figure 1.2 The login form.

Weaknesses in Authentication

There are several potential weaknesses related to authentication. The two biggest are that users may choose a weak password and that on most sites passwords are sent in plain text over communication methods that can be intercepted—notably, unencrypted HTTP over unencrypted WiFi. Weak passwords are vulnerable to a dictionary or brute force attack in which a script attempts to log in to a site using common passwords and eventually uses every possible combination of characters until it successfully logs in.

A less-common but still important concept is that of insufficient authentication (Figure 1.3). Authentication is insufficient if, for the kinds of transactions to be carried out, the proof of identity of the user is not strong enough to provide sufficient certainty for the site. The sample Vulnerable module has a feature that allows anyone to log in as any user simply by providing the user ID of whatever user she wishes to be. Especially in Drupal where user IDs are sequential integers and where the user ID 1 is all-powerful, this is probably a bad idea outside of an extremely controlled environment (such as a development computer that is never connected to a network). But it could be that the default username/password combination that Drupal uses is insufficient if your site is a financial website or contains valuable secret information. In that case you may want to use a third-party identity verification system based on a stronger authentication mechanism, such as an RSA SecurID token, sometimes referred to as an RSA key fob.

Figure 1.3 Insufficient authentication from the Vulnerable module lets an attacker become user 1, or 3, or 30, without any proof.

Caution

In the example Vulnerable module, there is a dubious feature that lets any user impersonate any other user on the site simply by specifying the user ID number in the URL at vulnerable/insufficient-authentication/1. Specifying the 1 is especially dangerous because user 1 on a Drupal site is a special user who has been granted all roles. This may be handy on a development site but is obviously dangerous for any other site. Figure 1.3 shows an account right after someone used this feature to become user 1 on this site.

It is up to each site to determine an appropriate level of authentication for its users. Often username and password are enough. However, as the example Vulnerable module shows, it is possible for a contributed module to create a situation that bypasses the normal login process and allows an attacker to gain access of another user.

Authorization: Permissions and Access

One thing that makes Drupal a great system to use is its rich system of roles and permissions. Permissions control actions that can be taken. Roles are groups of permissions that can be granted to users. A site can have an arbitrary number of roles, a role can have an arbitrary set of permissions, and a user can have an arbitrary number of roles. When a user has two roles, his or her total set of permissions is the union of the permissions for those two roles. Two special roles—anonymous and authenticated—are required on every site and define the permissions granted to any user based on whether the user is logged in or not.

In addition, Drupal has a system of specific object access, which allows third-party modules to define grants related to node and taxonomy objects. This allows a site to have private and public nodes depending on the taxonomy term applied to a node. This access system is covered in more detail in Chapter 7.

Going back to the bank example, once you have established your identity by an authentication means, you then may be limited in the actions you can carry out—that you are authorized to do—based on your permissions or on the level of authentication. For example, your ATM card and PIN are relatively easy to steal, so users who use this authentication mechanism are able to withdraw only a finite amount of money from the bank. On the other hand, if you go to an agent of the bank and present your passport and driver's license and then request to withdraw a much larger sum of money, the agent is likely to let you do so. You may be required to have a specific level of permission on the account to be able to withdraw all the money in the account or to close the account.

Weaknesses in authorization occur when a user is permitted to see data or perform an action that should not be allowed. For example, a module may show information that should be private, such as the email address shown in Figure 1.4, or allow a user to delete or modify content she should not be able to change.

Figure 1.4 Authorization bypass reveals users' email addresses.

The Vulnerable module contains an example that, even when used properly, bypasses these two types of authorization. It is available to all visitors of the site and shows user email address information for any users of the site based on characters found in their username. The style of the query bypasses several layers of what would normally be proper user authorization checks:

The list shows all users regardless of whether their accounts are active, though Drupal normally doesn't show profiles for inactive users.Email addresses should be shown only to users with the “administer users” permission.Only users with “access user profiles” permissions should be able to see this data.

This simple example shows how a module developer who wanted to share information could easily create a situation where data is easily available to site attackers. Later you will see how an attacker could combine this page with SQL injection to get virtually any data from a site.

Session Management and Weaknesses

The Internet is based on HTTP protocol, which provides no system itself for keeping track of users. When a user requests a page, the web server sends it back and the interaction is complete. When a user requests the next page, it may be handled by a different web server process or even a completely different physical server.

Imagine if, in the bank example, you first proved your identity to one agent of the bank and then when you wanted to make the withdrawal, a different agent at the bank helped you. To keep track of who you are, the bank might issue you a unique number. When you make a request to do something, you also provide your number. The agent compares that number to a list the bank keeps, and then the bank can be sure of your identity. This is basically how session ID numbers work for web applications.