It's Time to Get Your Cookies in Order

If you want to have a native, single sign-on solution that is deeply integrated into Drupal, there is really just one option: Bakery. If you aren't aware of the Bakery module, it is what creates single sign-on between sites like drupal.org and groups.drupal.org, as well as most of the DrupalCon sites.

If you're wondering why the module is called Bakery it's because it deals with the cookies, of course. A read through the module's code will introduce you to such cookies as the OATMEAL cookie, the CHOCOLATECHIP cookie, and a variety of others. I won't get into what they all do, but suffice to say that it's an amusing read.

Bakery is ideal for Drupal sites because it is capable not only of providing SSO, but also of syncing Drupal profile fields and user avatars — and handling some de-duping of accounts — on top of providing account proliferation across multiple sites.

Ways to Protect Your Websites

Any website can be vulnerable to a variety of security problems, regardless of its underlying web technologies, including Drupal. Yet the most common type of attack involves a visitor injecting ill-intentioned code that is presumed to be regular text. For instance, an attacker might submit a comment to a blog post, but instead of providing only innocuous text, he includes malicious JavaScript code, hoping that it will be rendered by the web browser of anyone later viewing that page. Another attack vector, known as SQL injection, works by submitting through a form field some SQL code that, if not handled properly, ends up as part of a database query, intended to execute an unauthorized statement, such as truncating or dropping tables within the database, setting passwords to known values, or stealing user sessions.

That latter type of foul play is well addressed by Drupal's database API layer, which, if used properly and consistently in one's custom code, can negate the risk of an SQL injection breaching one's defenses. Consequently, Drupal developers and administrators will more likely encounter the former type of attack.

Broadly speaking, there are two schools of thought regarding how best to avoid falling victim to any online miscreant attempting to force his code to be displayed in your pages' contents or URLs. It might seem that the safest defense is to never allow unvetted content into the website's database. This process of sanitizing all text beforehand could be thought of as "pre-filtering". Drupal generally takes the opposite approach ("post-filtering") — namely, allowing all submitted content into the database, but always sanitizing it on output.

Pronounced "drupal-art", noun referring to Drupal code that is both beautiful and artistic.

We previously explored the idea that software is art, one of many creative disciplines. We examined art through the eyes of both the layman and the artisan, and meandered from traditional art to software art. We looked at pseudo code and glanced at PHP. I looked for beautiful code in Drupal core and concluded that Drupal's beauty is not in its code, but in its API's.

Relational Art

Without the relation the artist has with art (the time and attention that goes into the work), or without the relation the art lover has with art (the time viewing, collecting and enjoying the work), art would be nothing more than an object of clay, canvas, or cloth. We find value in objects, but appreciate beauty through connections.

I find the deepest beauty in relational art; paintings and sculptures that embed relations within the art object itself, mostly those that depict people in loving relationships with each other. Renoir’s Luncheon of the Boating Party is a great example, showing multiple interactions of people, pet, food, and drink.

Are You a Gazelle or a Bank?

When thinking about the security of a site based on a system like Drupal, it's valuable to decide if your site is a gazelle or a bank; that can help you prioritize your actions related to security, and determine a strategy for securing your site. This article starts by explaining the bank vs. gazelle categories, and then gives ideas for how to protect your site depending on which kind you have.

The Asymmetrical Nature of Security

The first thing to consider when running a site is that as the site owner you have to be proactive in keeping your site 100% secure. An attacker only needs to find one vulnerability. This asymmetry creates one of the biggest challenges in running a secure site and often leads developers and operations teams to take extreme measures to protect their sites. It's not uncommon to hear about combinations of preventive and detective protection in multiple layers. Just one example I'm aware of: a site that uses a Denial Of Service prevention tool at the DNS layer, a CDN with a built-in web application firewall (WAF), and a WAF on the read-only-publicly-accessible staging server, all of which are in front of the actual content entry server which is only accessible on a private VPN. Lots of protection, right?

Drupal 8 is Going Mobile

Drupal 8 is due for release in the far future: late 2013. The future is a scary place. I keep hearing about all these "handheld devices" that are capable of strange things like storing whole record collections, perfectly copying the face of a human being, and accessing the internet over a mobile or wireless connection. People are using these "handheld devices" to do all manner of things, one of which is building websites. Drupal needs to catch up fast.

"Who's going to want to use Drupal on a small screen?" is something I've been asked over and over. Perfectly understandable. It's really hard to imagine using Drupal in the palm of your hand now, because the experience typically ranges from painful to unusable.

I often ask clients if their mobile traffic is less than average because users don't want access on the go, or because the experience is so bad they're going somewhere else.

If we make the small- and touch-screen experience more acceptable, who wouldn't want the freedom of using Drupal from anywhere-but-a-desk?

Social Security

Using People (and a Little Tech) to Solve People Problems

"He convinced his employer that the company could double its profits by merely unlocking the front door and allowing customers to come in." — Woody Allen, from "The Diet," in the collection Side Effects

The cost of security is usually measured in milliseconds, developer hours, and gigabytes of storage. But what parts of the tale do those metrics ignore? Consider Allen's joke: the company avoided theft, but at the cost of half of its business. (How the other half shopped through a locked door is left as an exercise for the reader.)

Most "security" focuses on technical issues — how to lock the door, so to speak, and which kind of lock to buy. Drupal's security advisories and the security documentation on Drupal.org are good examples of that phenomenon. This makes sense: when you're good with a hammer, everything looks like a nail. (Credit where it's due: Drupal's security team is very good with a hammer, and there are a lot of nails out there that need pounding.)

Breaches of "security" are very troublesome. But breaches in the social contract — such as spam, trolling, and use of someone else's login — can be just as bad. The advisories don't address such social issues, which can have a bigger business effect than a cross-site scripting hole. (Few people trust an e-commerce site where all the comments are spam.)

Here's the thing: You can't fight a social problem with technology alone. Who hasn't been driven away from a site that was "too secure"? Mandatory membership, administrator approval, IP filters, rate limiting, (broken) CAPTCHAs... all effectively "lock the door." At issue isn't the tools per se, but their application.

Curing Social Disease

Social problems require social solutions. While not driven by technology, they are enabled through it. Here are a few examples:

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.

Old Lessons for a New Problem

By now, you’ve no doubt been marinated in technical articles about security, to the point of being pickled in terminology and saucy advice. It’s too much! With all due respect to my fellow writers, most of what you need to know about security for your Drupal site you have already learned from your dad (or mom or granddad...) like I did, even though my dad never learned to use a computer, never heard of Drupal

Magic? No, not really; Dad wasn’t the least bit clairvoyant. What he had was a large body of advice, and that advice extends to the topic at hand, just as house construction is wonderfully analogous to web site building.

So, let me share some of those gems with you. I suspect you’ve heard them before, but we’ll breathe new life into them, like a movie version of "Hamlet."

Eliminate Headache Customers to Reduce Stress, Increase Morale, and Jumpstart Your Company's Growth

During a business strategy BOF at DrupalCon Denver, I suggested to the gathered freelance-types that they should fire bad customers. The reaction was immediate, visceral, and hostile! As I slowly backed toward the door I explained to 50 pairs of angry-eyes that firing ill-fitting, high-maintenance customers is a necessity advocated in many business books. They were having none of it and I slipped out just before I was hook_user_deleted on the spot. Clearly I'd hit a nerve; this is something that needs to be discussed more in our community.

I read an interesting blog post titled "Why Cheap Customers Cost More", in which web designer Sacha Greif explained why customers who buy lower-priced services have high support needs. The article postulates that low-price offers attract "dumb" customers (his word, not mine). Not dumb as in unintelligent but ignorant about the products being purchased so they make a decision based on the only thing they do understand: the price.

On the surface, this rings true, but ultimately I disagree. At Volacci, certain low-priced customers DO tend to have higher needs. However, it's not because of ignorance. We have "less informed" customers at all price points that are wonderful customers because we've earned their trust. In fact, some of our most successful, lowest-maintenance customers fall into this category. We call them "B" customers.

Common SELinux Configuration for Apache

SELinux is a powerful tool for controlling what applications are allowed to do on your system. SELinux is a labeling system where every process and every object (files, directories, devices, network ports, etc.) gets a label. Then a large rules database, called policy, is loaded into the kernel. The kernel, based on the policy, controls what each process can do based on its label, and the label of the object it is trying to access. For example SELinux allows a process with the Apache label (httpd_t) to share data labeled as "read/only Apache content" (httpd_sys_content_thttpd_sys_content_rw_t). SELinux will block Apache processes from reading data labeled as user's home content (user_home_t) or database data (mysql_db_t). Apache processes can listen on ports labeled as the Apache port (http_port_t) but can not connect to the ports labeled as the mail port (smtp_port_t).

SELinux provides confinement on an application if the application has been hacked, even if the application is running as root. If policy says the Apache process is only supposed to read Apache content, then even if a hacker gets uid = 0 (the root user), he will not be able to turn it into a spam bot; he will not be able to read credit card data in your home directory; and he will not be able to destroy log files. The hacked process will only be able to act as an Apache process.

"Well that is all fine and good Dan, but Apache can be configured in a hundred different ways. Can you give me some idea of how to stop SELinux from complaining?"

A while ago I wrote an article called: What is SELinux Trying to Tell Me? The Four Key Causes of SELinux Errors. In the article I explain that the four causes of SELinux messages are:

• You have a labeling issue.
• You changed the default configuration and you need to tell SELinux about it.
• An application or SELinux Policy has a bug.
• You've been hacked.

In the rest of this article, I will explain how to deal with each of these scenarios.