fromAugust 2012

Practical Website Security

You Will Be Hacked

You Will Be Hacked

Warning: this article is going to be practical -- bordering on cynical. Use common sense and apply cautiously. Also, this is a generic article. If you are tasked with safeguarding the personal data of thousands of policemen or a few million credit card numbers, this article alone is most definitely not enough. Still, every bit helps.

Know Thy Enemy and Other Basics

One kind of enemy is the guy who wants to build a botnet for sending spam, performing DDoS attacks, and other nefarious activities. For this type of person, it won't matter at all which computer he manages to take over (in short, "own"). If breaching your security takes more than the most minimal of efforts, these people are kept at bay because there are millions of easier targets out there. Keep your software up to date: most server OSes have simple ways to keep up with security updates in a fully automated, unattended way. Make sure your whole stack is up to date -- for example, if you installed something from source, then it's your responsibility to keep it fresh. Have a basic firewall going.

Another kind of enemy is the script kiddie who does it for the "lulz", bragging rights, or the thrill of it. These types of people are unpredictable, as they have no clear motive or goal. Nor do they have many skills.

You will be hacked: drawing of defender and attacker is to scale.Most attackers fall into these two categories, practically zero skills just running pre-made tools which exploit well known and already fixed bugs. The only difference between these two large groups are the scale and the goal. You can and should familiarize yourself with the tools they use and run penetration tests against your host. However, pen-testing is a broad topic which couldn't fit inside this article. There are, of course, a lot more types of attackers but I will mention only one more: someone moderately skilled who harbors a grudge against you. In this case, you are very likely doomed and you can do very little but ensure your personal security is in decent shape.

Keep Your Own Affairs in Order

Before you can even think of keeping a website secure, you need to make sure your personal affairs are in order. NEVER reuse a password. It is an incredibly common source of attacks. I use SuperGenPass which exists as a bookmarklet, a browser extension, an Android app, an iPhone app and even just a plain HTML+JS page. It takes a master password, the domain name, and cooks up a hashed password. The master password never leaves your computer. Unless someone has gotten a malware on your computer, you are good. To avoid said malware, presuming you use Windows, just install Microsoft Security Essentials. If you use Linux, well, let's face it, we are a fringe minority no one bothers writing desktop malware for. If you are using Mac OS X, then ClamXav is free and open source. Add a home router as a basic firewall just to avoid any automated attack your computer could get if it would be sitting "naked" on the Internet. Using an open source firmware with your router is a wise idea. Pick a recent build from or use dd-wrt if your router is not supported by Tomato. During the writing of this article, the Coding Horror blog has published an article on routers and open source firmware, both the article and the comments are worth a read.

Another password tactic is to use throwaway long passwords from places like the GRC's Ultra High Security Password Generator and simply ask for a "password reset" every time you need to log in. Most sites can remember you with a cookie and this is less cumbersome than it sounds. However, this leads to our next topic: your e-mail account.

Your E-mail Account

Your e-mail account is the master key to too many (all) things, so make sure that it's secure. This is harder than it sounds. You are using e-mail all the time so you are more likely to log into it from places you probably shouldn't. Two-factor authentication is a good way to protect your account. For example, Google provides an Authenticator mobile app which generates passwords changing every minute or so. Another two-factor solution is the Yubikey (see the sidebar for that). While I called this "two-factor," that name in general means two of "what the user knows" (password), "something the user has," and "something the user is" (fingerprint, iris etc). For this article, "two-factor" will mean a password and a device providing one-time passwords.

While the sites themselves employing two-factor authentication might have security holes, for the average attacker the two-factor authentication itself is simply impenetrable -- meaning the attackers can't log in as you. However, malware is getting trickier day by day and there have been reports of trojans attacking online banking systems by adding an illegitimate transaction to real ones, completely disregarding how you logged in. Similarly, a malware might search your Gmail box, once you have securely logged in, for e-mails containing "password," and mail the findings to the attacker.

Also, once you have locked the front door, don't leave the windows wide open -- Gmail allows you to add a backup phone number. There have been a lot of stories lately how attackers have fooled phone companies and used the backup phone number to take over accounts. This is nothing new and shows a very important point: trusting other companies blindly with your security is a foolish idea. Google so far has proven trustworthy while most phone companies have not.

Your Mobile Phone

Your mobile phone is constantly logged into your e-mail, so it is a master key. It is accessing the Internet from all sorts of networks which are not under your control at all. Also, you are installing all sorts of things on it, often without thinking. This makes it a juicy target for attackers. On Android, when you install an app from Google Play, there is a permissions screen. Read it. Why does a game need access to system files and send SMS, hmm? Also, I understand you are a hacker, a tinkerer, a developer who really must install APKs from who-knows-where, but you need to think extremely hard when doing this. Is that application worth jeopardizing your entire digital life? Because -- alas! -- that's what's at stake if you install a malware on your mobile phone.

So When are We Done?

If someone wants your data and/or your server badly enough, they will have it. That's a fact. (Locking it in a bunker and making sure it has no connection to the Internet is not enough. Ask Iran how well that worked against Stuxnet.) In this game, the defender is always losing. The traditional rule was to make it more expensive to own you than it's worth. This is surely wise advice, but for you to place an exact figure on the pile of data you are sitting on is likely a futile exercise -- unless you frequent black data markets. Equally, how could you even guess what it costs to hack your server? So let's delete this rule because you can't apply it.

Instead of being "done" with security, you need a comprehensive set of policies and best practices that gets you a lot of bang for the buck. Only policies can protect against social engineering. To give you a ruse most developers would likely fall to: you get an e-mail saying, I filed this ticket here; you click, provide your username, and password to a fake page, and the attacker now has access to the issue tracker, which surely contains all sorts of information that can be used to further the attack.

One might say that this won't work because you just need to pay attention to your browser and make sure you are on the right page. This is nice-sounding advice, but utterly useless. Relying on your employees to actually look at the URL bar every time they need to supply a username and a password leads nowhere. Instead, you should strive hard to decrease the frequency of such events.

OpenID helps (Jira and trac both support it). You only have one provider to keep secure. And a well-chosen OpenID provider -- unlike most websites -- has security expertise. And definitely choose one with two-factor authentication. Google is one, Yubikey is another. Yes, the OpenID login process is awkward but it doesn't take too long to learn to supply a URL instead of entering a username and a password. Note that even Facebook supports OpenID although they don't advertise this widely. Speaking of Facebook, your account there is a great place for attackers to learn all sorts of information (name of your partner, dog, or college) which you might have used for passwords and security reminders. As for security reminders, do not, ever, ever answer such stupid questions as "what was your first school" with your actual school's name. Treat it as a password. Yes it's a hassle but at least you won't be hacked in two minutes by some trivial Googling for your CV.

For non-OpenID sites, like github, you should keep a list where your colleagues / employees will likely have to supply username and passwords. Anything not on that list should be treated with extreme caution. When was the last time you actually needed to supply your github password? My github session cookie expires on Dec 31th, 2021. So, the github login will not be on the "things you do everyday" list; therefore, it should be suspect. Also, obviously, everything in the "own affairs" section should apply to everyone. Harbor no illusions, someone will do something stupid and you will be hacked, most likely by an employee getting a malware or dropping a password where they shouldn't. You can test against this -- create a Skype account with a very similar name to yours and try to coax a password out of an employee. Notice how much obeying the article so far helps here: some sweet talking ("we have a problem, I need to check it logged in as you") might be enough to land you a password to some site. However, as no one shares passwords, the attack hopefully stops there (unless the password was to a site that itself holds passwords, like an issue tracker). If you picked two-factor or OpenID, it makes this much more difficult; asking for someone's OpenID password will most likely set off alarm bells. Good security works like this: it makes each attack harder and limits the damage when an attack eventually succeeds.

A Practical XSS Trick

One of the most common security holes in a typical Drupal website is an XSS hole (once you have your stack up to date). As I mentioned above, for most kind of attackers (the automated variant) this is a non-starter: for an XSS attack to work, they need someone logged in as admin to visit the harmful post they created, and that's just too slow. So, protecting against XSS is both challenging and, at the same time, not the highest of priorities. What you can do is a simple trick which won't help in all cases but is "cheap" from a work perspective: fill in <script>alert(‘xss');</script> everywhere when you are testing. Usernames. Node titles. Comment subjects. All of that. This might actually reveal XSS holes and can be integrated with everyday testing, so it requires little extra effort.

The Yubikey

The Yubikey is a very small and relatively cheap device ($25) which creates a one time password every time its button is pressed. It works with all sorts of hardware because it emulates a USB keyboard -- there is no client software necessary and all you need is a USB host. All PC and Mac laptops have had that for at least ten years now; most tablets also, and you can get micro USB host mode cables for one or two dollars that work with a good number of phones as well. Server side integration is possible with most open source software, including Drupal. Alas, most websites do not bother setting it up. Also, you can use it as a replacement for the Google Mail Authenticator app but this unfortunately does require additional software -- which makes it a little cumbersome. On the other hand, unlike a smartphone a small keychain fob is not as likely to be stolen. As an alternative to Gmail, supports the Yubikey natively. And you do not need to use Google as your OpenID provider because there are OpenID (and other SSO protocol) providers that support the Yubikey as well. Also, the Yubikey has two "slots," so besides the one-time-password algorithm you can make it store a static password. You can use this for another sort of two-factor security: type in a password you remembered, then press the button to add the long static password stored in the Yubikey. Use the results as your Supergenpass master password.



From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.