Drupal security best practices

Editor's Notes

• #3: 5 steps
• #4: Sometimes the mythology clouds the full issueWhen we talk about security in the context of computers, our minds might tend to wander toward movies.But that’s not the full picture.So it might be helpful to back out of computers and talk about security in a general sense.
• #5: The thing you’re trying to get with security is freedom from fear of harm.Your person, family, belongings, money, reputation, country…Each of these things has a different protection (examples)In each case, you’re creating some barrier be it physical or social between the thing that causes you harm and the asset you’re protecting.The more barriers you put, the safer a thing can be
• #6: If you’re keeping some valuables at home, there may be additional safety by having a high gate, a strong lock on the door, and a safe to keep them in.This is in nice layers. When people say security is only as good as the weakest link, they’re not talking about…They are talking about how you’re protecting each entry into the house.
• #7: Locking up your things inside a safe, inside a house, inside a fence, on an island surrounded by lava might be really safe, but doesn’t make it easy to get those things. Writing down a password to the computer ON the computer is pretty convenient, but obviously stupid.Depending on the ease we need to get at those things we should balance the amount of security we’re willing to afford to get it. Making anything easy for one person to obtain makes it at least fractionally easier for someone else to obtain.In spite of any protections you might take, a determined crook with enough time will probably, eventually, take your valuables.
• #8: If you’ve got some valuable thing, you hope it won’t be stolen or broken, you you’ve still got to have some plan for when it does.It’s not just valuable stuff, either. People die. Having security for your family includes not just alleviating their fear of your death, but also alleviating their fear of what they’ll do when you die.This is just one aspect of defense in depth.In the real world, we take a lot of this stuff for granted. What people don’t seem to do very well is translate it to computer and online security.
• #9: So what do we need to port over from the real world to the digital?We need layers.We need to protect from every angle.We need to balance security and convenience prudently.We need a backup – just in case.Defense in depth.
• #10: Password strength is a simple thing, but is an obvious problem.Of the 23k people using Drupal 5 with the usage modulein January, 230 were using the password strength module to alert users to the strength of their passwords. We can beat ourselves up all day with XSRF and XSS and SQL injection, but our clients are stabbing us in the back here.One of the less immediately obvious, but more effective ways to get a password is via social engineering/hacking.Social hacking is getting to know a person or company, and integrating yourself as though you belong to obtain information you shouldn’t have.
• #11: MySpace phishing attack – 34k usernames and passwords81% alphanumeric,Almost 10% just letters.Another point: Passwords aren’t just a point of failure on the site you use them onThere’s little you can do to your site can prevent a user from giving away his password to someone who shouldn’t have it.
• #12: Things to think about passwords…People don’t care – you can set up a weak password for them; they never change it.Letters as numbers – hackers are onto you.Some good ideas – bookmark that lets you use a master password. Use mental masters.Use certs.When sharing passwords, encrypt them.Vidoop – now defunct – call and photo
• #13: Why is password security and other seemingly low-level security important?Because a clever hacker will abuseDon’t put a sign outside that says “door unlocked, vault within”.Poor security where its easy to fix is usually an implication of worse security where its harder to fix. It’s an invitation to hackers to try.
• #14: Permissions are important because after you use a password, you want to be able to do things with the system.Penn is a good example of authentication vs authorization.Just because you get into the system doesn’t mean you should see everything. Unauthenticated users are users too.Keeping secure admin passwords is important because after a site is deployed, we typically don’t remove those developer accounts.
• #15: A weakness that makes a threat possible. Not necessarily likely. Doesn’t encourage it. Just has potential.These are the ones we should be on the lookout for.
• #16: Every input should be filtered and so should every output. Should really have a good idea of what input is tainted by external influence in your system versus what data you know is clean.Always filter for what you want to have, rather than removing what you don’t want.Validation in Drupal isn’t just validating for types of values submitted, but also validating the data on its own, especially for output. Printing CCK fields is naughty.
• #17: Number of ways for this to work. One example.
• #18: Harder but more insidious.
• #19: Here’s what the code looks like.Don’t do this with Drupal. Use the FormAPI. Includes extra fields that prevent forged requests.
• #20: Drupal is mostly safe if you use the drupal functions.Drupal doesn’t use PDO – yet.Watch out for proper quotes around escaped values and IN clauses.
• #21: How do we test for this stuff?Automated testing suites – Acunetix.Still requires someone who knows what they’re doing at the wheel.Acunetix is a tool. Be sure your using the right tool for the right job. If you’re looking for ways to make your server more secure, Acunetix is the wrong thing.Module security audits. Surprised that there isn’t a team for this.Like to start site-wide peer code reviews. Look at template code, look at custom modules.Are you going to catch everything? No. But we can limit bad things. We can do enough that mistakes become easier to find and to avoid when we’re working.
• #22: Drupal issues security advisories against drupal core directly and hopefully provides timely updates.Contributed modules and themes are also announced here.Calendar? Date? On 7/29 Remotely exploitable XSS attacks were announced. Good feed to get on, especially if you want to find out about vulnerabilities before your clients see it in their logs.Be a good Drupal citizen. Report security issues properly.
• #23: Move from app security out to computer securityRestrict the types of files that a user can upload so that they’re not uploading file types that the server will execute. Drupal settings let you set the upload type to wildcard – naughty.File sizes. Need to work on this. Take all server space, take down server.Giving clients access to directories. Suexec. SFTP vs FTP.
• #24: Unix mode settings. Sticky bit used with umask to make new files take on their directory’s permissions.
• #25: Selecting a host for security can be tough, because it’s costly to move and maintain servers. I’m going to say “host” but that could mean your corporate internal hosting too.Hosts that are worth the extra money will do most of this for you, but be careful. There are hosts that claim to offer “fully managed” hosting, but what they really mean is that you’ll pay extra to talk to a tech than then will charge you extra for what he should have been doing all along, or tell you that it’s a service they don’t provide.Be sure that your host launches you on an up-to-date server, with an OS that you can keep updated. You don’t want to be stuck using Fedora Core 4 when they stop supporting it just because your host has some software they bought 15 years ago that helps them launch sites automatically.If you’re not regularly getting messages about your host updating things on your server, you should check into that. For each time that Drupal issues an advisory – we’re on 6.13 already – you’ve got 20 applications running that all probably require an update to keep them secure.There are things you should be doing to keep your own server secure via PHP, especially if you’re giving clients access to your server. Check out the book Essential PHP Security by Chris Shiflett, which talks about some basic settings that will prevent errant code from doing bad things. Remember, layers of protection – If someone manages to get code on your server somehow - a client? – then limiting how that code can cause harm is a good idea from the get-go.Performance can impact security. A slow server fielding a low-yield DDoS attack is going to get crushed. A fast server is going to have an easier time. Any server with mod_evasive is going to have an even easier time.Quality of your host can play a big factor in security. When you place your trust in someone who can just walk off with all of your stuff, you gotta pick hosting that’s not run from a shack. … Look for service that isn’t going down every half hour. Look for redundant systems for power, network, storage. Look for service that actually answers the phone. You want to have it and you never want to use it. It’s like insurance.
• #26: When all else fails.
• #27: Poor security has an impact on everyone. Bot-nets.In the end, it’s about keeping our risk low and making our users feel safe about using the sites we build.
• #28: Obviously, this is incomplete.