Out of the box, Drupal does a good job of providing securely written code. For instance, core modules sanitize user input and interactions with the database use Drupal's database API to prevent SQL injection attacks. However, Drupal doesn't enforce strong passwords by default which can lead to a scenario that is not too hard to imagine.
Let's say a new content editor named David has been hired. To quickly get him up and running he is given the username david and a password of david123. David logs in and gets to work and doesn't bother changing his password - after all, david123 is easy to remember! (This scenario may seem contrived, but I fear it is all too common.)
It's not unusual for Drupal themes to add an author's actual username into content. An attacker can just scan the text or source code and find something like this:
<span class="username" about="/user/88" typeof="sioc:UserAccount" property="foaf:name">david</span>
- A quick glance and the attacker knows there is a valid username david.
- The attacker tries logging in with some common weak password patterns (ex. david1, David1, david123).
- ...and Bingo! With david123 the attacker has logged in and the site has been compromised.
If the compromised user has admin privileges or can use a WYSIWYG editor that allows PHP execution (which we never recommend), then it's possible the whole server is at risk. In a nutshell, security's not just about depending on securely written code; enforce strong passwords from the start. (While you're at it, make sure admin pages are served over SSL.)
Try the following:
- Password Policy module (enforce strong passwords and hey, expire them too?!)
- Use a preprocess hook or edit your template files to remove the display of user info (Hint: sometimes themes will also add the username as a class class="author-david")
- Secure Pages module (force admin pages to be served over SSL)
There is plenty more you can do, but using SSL and having a strong password policy without advertising your usernames is a solid start. Even better would be to explore two-factor authentication, but we'll leave that for another blog post.
* Yes, Drupal will lock the user out after 5 unsuccessful login attempts, but a cunning attacker can keep trying from different IP addresses. [Correction: Originally I had written that the attacker could lock out the legitimate user. Subsequent online comments have pointed out that Drupal only locks out attempts from the originating IP address and that the real user always has the option to reset his/her password. Thanks for the feedback!]