Sep 06 2019
Sep 06

 


Today, IT security is paramount to succeed in business. Enterprises are spending hefty amount on security than ever before. Progress in both security and hacking technologies such as intrusion detection systems, honey pots, honeynets, and other various security-related hardware and software solutions are showcasing the pressing need for transformation in the information security domain.

One of the reports by Gartner cited that enterprises in India alone are going to spend laboriously on the information security front which will mark up to US$2 billion in 2020.

The increasing awareness on the benefits of the risk assessment and the realization of the fact that security is one of the driving forces for digital transformation are boosting enterprise security globally. 

The battle between open-source and proprietary software has been throwing a fit since long. Multiple issues and concerns are being examined and scrutinized by both sides of the story. In the most recent phase of this fanatical dispute, both camps have inspected the issue of security with serious tenacity.

Having said that, let’s take a sneak peek into this blog for further insights on the same.

Myths Are Meant to Be Debunked

Proprietary software is more secure than open-source software. This myth comes from many prejudices. But a commercial license doesn’t assure security. Unlike proprietary software, open-source software is transparent about potential vulnerabilities.

#Myth1: Anyone can view the code 

Because it is open source, anyone can view the code. People often want to argue that being able to view the code allows nefarious hackers to look at it and exploit vulnerabilities.

However, this openness enables collaboration. Unlike, say, one proprietary software, which is developed and is maintained by a single company, Drupal is developed and maintained by more than one hundred thousand programmers around the world. These programmers might work for companies that compete with each other, or they might volunteer to create something new that’s then given away. For free.


In fact, in 2015 Google open sourced its artificial intelligence engine, TensorFlow. Something which is a core part of its business. It hoped more developers would make the software better as they adapted it to their own needs. And it did, by making it open source, Google boasts of more than 1,300 developers, outside Google, have worked on TensorFlow making it one of the standard frameworks for developing AI applications, which could bolster its cloud-hosted AI services. 

#Myth2: Proprietary software are secure and not prone to attacks

There have been multiple instances in the past that depicts that proprietary software has been attacked several times. Such as:

Melissa Virus and ILoveYou Worm - spread through Microsoft Word email attachments. The email contained attachment. If the victim’s system had the Microsoft outlook application installed, then the virus would send the email to 50 too all contacts in the Outlook program’s address book. would also overwrite & consequently destroy various types of files on the victim’s device including MP3 files, JPEG files, and more. It led Microsoft to shut down its inbound email system.

Wannacry - a worldwide cyberattack that took place in 2017. It was a ransomware crypto worm attack that aimed at computers using Windows operating systems, encrypting all the files on hard drives on these machines. It didn’t let users access the files until they paid a ransom in the cryptocurrency Bitcoin.

The WannaCry attack impacted major entities all over the world, such as the National Health Service in Britain and Scotland, the University of Montreal in Canada, State Government websites in India, and Russian Railways.

With that said, it's evident that proprietary software is also easily vulnerable to attacks!

Although countermeasures like anti-virus programs and security patches were implemented to mitigate the threats and weaknesses, the long-term and especially exorbitant effects of these dangers have been engraved for permanent into the memories of people all over the world. This is because these attacks not only damaged vital electronic data but also shut down business operations and services, and facilitated malicious infiltration and theft of money & proprietary information.

History of Open source Software

The term “open-source”, popular since its inception in the late 70s and early 80s has come from a revolution, “open-source revolution”, which completely revamped the way software is developed- resulting in the birth of the community-generated software development method.

Box with text written inside it

In 1971, Richard Stallman, a young software engineer from Harvard, joined the MIT Artificial Intelligence Lab with the intent of developing computing platforms. After serving for a few years in the early 1980s, the MIT Lab became extinct due to the booming of proprietary software in the market and lost its talented developers to privately held tech companies.

Stallman, who was closely involved in the field knew customers’ software requirements believed customers should be empowered enough to fix and debug the software themselves instead of simply operating it.

“Users should be empowered enough to fix and debug the software themselves-instead of simply operating it”

The majority of software until now was controlled in its entirety by the developer where individual user rights were completely discarded. This was also a pain point for MIT AI Lab since they failed to incorporate this feature into their software development strategies.

The Disembarkation of the Free Software Movement

But this was until 1984. Post evaluation, Stallman began his GNU Project. Initiating with a compiler, GCC and a new operating systems-Stallman felt that GNU project was the major turning point in the evolution of free software community.

“The Free Software Foundation was formulated to let users run the software as they wanted”

Stallman believed that software should be available for free in terms of accessibility. Hence, the Free Software Foundation (FSF) was formulated so that users can run, modify, update, and disseminate software in the community.

Later on, he also introduced the concept of copyleft, wherein a program is first copyrighted, and then additional distribution terms are added for its further use.

Challenges Associated With Proprietary CMS 

Proprietary CMS comes up with a set of restrictions which makes it less flexible in comparison to open-source software. 

“The contribution and development teams of proprietary cms are smaller, which makes it evident that there is a probability of missing out on mistakes and bugs in the code”

It might appear that closed source software or proprietary software is more secure since the code is not available. But unfortunately, it is not the case! The contribution and development teams of proprietary CMS are smaller, which makes it evident that there is a probability of missing out on mistakes and bugs in the code.

You might not know what issues the proprietary system has had in the past, or is having currently because the provider of the proprietary CMS isn’t going to voluntarily reveal this information. This sets a major drawback for proprietary CMS users in terms of security as well.

Let’s further see the challenges associated with proprietary CMS-

Not many customizations options

Since these proprietary CMS are developed for a specific kind of industry and audience, it gets difficult to customize the website to fit the exact needs of the people. Users are not building their system so it's obvious that they will have limited flexibility options.

Portability is beyond the bounds of possibility

Users don’t have an option to extract data and files out of their system with a proprietary solution. They are quite restricted because they won’t be able to even move their website from one hosting service to another.

“Several CMS vendors don’t upgrade their platforms, so it's better to do a bit of research first and then jump onto doing business with a vendor”

You don’t have any option other than trusting the company blindly

Since the company owns the platform and the storage space your website will be built upon, you’ll have to manifest a lot of trust into your vendor. They will have to continuously develop and refine their software, to handle their consumers’ needs better. The vendor should also be in reach whenever you need assistance with your website

Several CMS vendors don’t upgrade their platforms, so it's better to do a bit of research first and then jump onto doing business with a vendor.

You are just renting software

Even if you have bought the proprietary CMS, you won’t own the code it's built with. It is not yours and hence requires a monthly rent from you, to keep your website running.

Benefits of Open-source Software

“People in the open-source community come forward to find solutions, assist each other, and to share extensions that would benefit the masses”

  • It is open-source!

This implies that the source code is available for anyone who wishes to study it, analyze it, and modify it in any way.

Thanks to this feature that people can easily extend the code and add specific functionalities as per their requirements.

  • An open-source CMS is maintained by the large community

There is always a primary group of developers, similar to WordPress but it is also supported by its user base. People in the open-source community come forward to find solutions, assist each other, and to share extensions that would benefit the masses.

Rectangle with various lengths of horizontal bar
Source: Sas.com

  • An open-source CMS can be hosted ubiquitously

Most of them, like Drupal, offers one-click installs in the control panel of the accompanying hosting service, which again is very user-friendly and comfortable.

  • The CMS software itself is usually free of cost

You can easily make use of plenty of extensions, themes, and a variety of tools for free. However, there are plenty of paid extensions and themes as well. Some solutions can only be leveraged with paid software. An open-source CMS is usually the most budget-friendly solution.

Alternatives to Proprietary Software

It is interesting to see that there are so many open-source software alternatives for the existing proprietary software which are equivalent or more reliable, secure, and flexible. 

If you are contemplating to migrate from proprietary software to open-source, you can surely - that too with ease!

Software Category

Proprietary Software

Equivalent Open-source Software

Operating System

Microsoft Windows

Linux Ubuntu

Browser

Internet Explorer

Mozilla Firefox

Office automation

Microsoft Office

Open Office

MATHWORKS

MATLAB

Sci Lab

Graphics Tool

Adobe Photoshop

GIMP(GNU Image Manipulation Program

Drafting tool

Auto CAD

Archimedes

Web Editors

Adobe Dreamweaver

NVU

Desktop Publishing

Adobe Acrobat

PDF Creator

Blogs

Blogger

WordPress

Mobile

IOS

Android

Media Player

Windows Media Player

VLC Player

Database

Oracle, Microsoft SQL Server

My SQL, Mongo DB, HADOOP

Server

Microsoft Window Server

Red Hat Server, Ubuntu Server

Web Server

IIS

Apache

Open-source Security in Drupal

Drupal, having a proven track record of being the most secure CMS, has been rolling with punches against critical internet susceptibleness. Thanks to Drupal security team for earnestly finding anomalies, authenticating them, and responding to security issues.  

The responsibilities of the security team include documentation of these identifications and alterations made so that developers don’t feel heebie-jeebies when faced with similar kind of situation.

“Drupal community comprises of over 100,000 contributors towards its enhancement”

Besides, the team also assists the infrastructure team to keep the Drupal.org infrastructure secure. They ensure that any security issues for code hosted on Drupal are reviewed, reported, and solved in the shortest period possible.

Important features that make Drupal 8 the best WCMS in regards to Security-

  • The Security Working Group (SecWBG) ensures that Drupal core and Drupal’s contributed project ecosystem provides a secure platform while ensuring that the best practices are followed.
  • The community makes sure that people are notified the day patches are released, which are released every Wednesday for contributed projects, and the third Wednesday of every month for core, usually for a fixed period.
  • Drupal abides by the OWASP ( Open Web Application Security Project) standards and its community is devoted towards prevention of any security breaches.
  • Drupal community comprises of over 100,000 contributors towards its enhancement. An open-source code base, where contributed modules are properly reviewed, verified, and sent a notification if that module is acceptable for use.
  • Apart from encrypting and hashing the passwords, Drupal provides those modules which can support two-step authentication and SSL certificates.
  • Any member can make changes to Drupal modules and report any issues or bugs that occur in their system.
  • Access controls offered by Drupal is a superb feature. Dedicated accounts can be created for certain user roles with specified permissions. For instance, you can create separate user accounts for Admin and Editor.
  • It’s multibranched cache structure that assists in reducing Denial of Service (DoS) attacks and makes it as the best CMS for some of the world’s highest traffic websites like NASA, the University of Oxford, Grammys, Pfizer, etc.

Statistics Says It All

Sucuri, a security platform for websites, curated the “Hacked website report 2018”. It evaluated more than 34,000 compromised websites. Among the statistics it shared, one of the factors was to juxtapose the affected open-source CMS applications.

drupal-sucuri

The results were clearly on Drupal’s side declaring it a better WCMS than other leading platforms for preventing safety hazards.

The infection crept in these websites due to improper deployment, configuration, and maintenance.

Additionally, Cloud Security Report by Alert Logic also marked Drupal as the website content management system with the least number of web application attacks.11 Columns and 8 rows with text written inside them                                                                        Source: Alert Logic

Difference Between Open-source and Proprietary Software

Factor

Open-source

Proprietary

Cost

Open-source software is free which makes it an alluring option if you have in-house capacities to meet your business requirements.

Proprietary software costs differently from a couple of thousand dollars to one hundred thousand dollars, depending upon the multifaceted nature of the framework needed.

Service and support

Open-source software communities of developers are huge and steadfast which helps clients with prompt solutions to their problems.

Proprietary software vendors offer progressing backing to clients- a key offering point for clients without specialized mastery.

Innovation

Open-source software boosts innovation by providing users the opportunity to modify, append, or distribute as per their requirements.

Proprietary software vendors don’t permit its users to view or adjust the source code, thus making it unfit for organizations who desire scalability and flexibility.

Only developers can incorporate new features to the product as and when requested by users.

Security

As open-source code is available to everybody, it increases the possibility of finding more vulnerabilities easily. 

It is also worth noting that open-source communities fixed security vulnerabilities twice as quickly as commercial software vendors do.

Proprietary software is considered secure as it is developed in a governed condition of the employees having a frequent direction.

However, getting rid of the possibility of backdoor Trojans as well as lowering the threat of any other bugs or obstacles can be troublesome in proprietary software.

Availability

Open-source software is available for free on the web with 24*7 support from the community.

Proprietary software is accessible if the companies have the rights to the bundle or they have purchased from the respective vendors.

The trial version is also accessible for free to test.

Flexibility

As organizations aim at deriving more business values from less, open-source software can deliver high flexibility, lower IT costs and increased opportunities for innovation.

With proprietary software, such as Microsoft Windows, and Office, companies are required to upgrade both software and hardware on a timely basis. Updates must be installed for the proper working. However, not all updates are flexible with all the versions of the software.

In The End

Website security has always been a cause of hindrance in the journey of digital transformation and survival due to several potential threats. 

Open-source software can be considered as a befitting solution than a closed source or proprietary software. Further, this report indicates that there is an obvious desire among companies to adopt open-source technology and also prioritize the task of enhancing security in their organization.
Rectangle with text written inside Source: Gartner

However, it all depends on the preferences and needs of the organization and the on-going project for their digital business.

Drupal, an open-source content management framework, comes out as the most secure CMS in comparison to the leading players in the market.

It has been the pacesetter when it comes to opting the security focussed CMS. More individuals working on and reviewing the product always means a higher chance of a secure product!

Jul 08 2019
Jul 08

Part of my day job is to help tune the Cloudflare WAF for several customers. This blog post helps to summarise some of the default rules I will deploy to every Drupal (7 or 8) site as a base line.

The format of the custom WAF rules in this blog post are YAML format (for humans to read), if you do want to create these rules via the API, then you will need them in JSON format (see the end of this blog post for a sample API command).

Default custom WAF rules

Unfriendly Drupal 7 URLs

I often see bots trying to hit URLs like /?q=node/add and /?q=user/register. This is the default unfriendly URL to hit on Drupal 7 to see if user registration or someone has messed up the permissions table (and you can create content as an anonymous user). Needless to say, these requests are rubbish and add no value to your site, let's block them.

description: 'Drupal 7 Unfriendly URLs (bots)'
action: block
filter:
  expression: '(http.request.uri.query matches "q=user/register") or (http.request.uri.query matches "q=node/add")'

Autodiscover

If your organisation has bought Microsoft Exchange, then likely your site will receive loads of requests (GET and POST) to which is likely to just tie up resources on your application server serving these 404s. I am yet to meet anyone that actually serves back real responses from a Drupal site for Autodiscover URLs. Blocking is a win here.

description: Autodiscover
action: block
filter:
  expression: '(http.request.uri.path matches "/autodiscover\.xml$") or (http.request.uri.path matches "/autodiscover\.src/")'

Wordpress

Seeing as Wordpress has a huge market share (34% of all websites) a lot of Drupal sites get caught up in the mindless (and endless) crawling. These rules will effectively remove all of this traffic from your site.

description: 'Wordpress PHP scripts'
action: block
filter:
  expression: '(http.request.uri.path matches "/wp-.*\.php$")'
description: 'Wordpress common folders (excluding content)'
action: block
filter:
  expression: '(http.request.uri.path matches "/wp-(admin|includes|json)/")'

I separate wp-content into it's own rule as you may want to disable this rule if you are migrating from a old Wordpress site (and want to put in place redirects for instance).

description: 'Wordpress content folder'
action: block
filter:
  expression: '(http.request.uri.path matches "/wp-content/")'

SQLi

I have seen several instanced in the past where obvious SQLi was being attempted and the default WAF rules by Cloudflare were not intercepting them. This custom WAF rule is an attempt to fill in this gap.

description: 'SQLi in URL'
action: block
filter:
  expression: '(http.request.uri.path contains "select unhex") or (http.request.uri.path contains "select name_const") or (http.request.uri.path contains "unhex(hex(version()))") or (http.request.uri.path contains "union select") or (http.request.uri.path contains "select concat")'

Drupal 8 install script

Drupal 8's default install script will expose your major, minor and patch version of Drupal you are running. This is bad for a lot of reasons.

Drupal 8's default install screen exposes far too much information

It is better to just remove these requests from your Drupal site altogether. Note, this is not a replacement for upgrading Drupal, it is just to make fingerprinting a little harder.

description: 'Install script'
action: block
filter:
  expression: '(http.request.uri.path eq "/core/install.php")'

Microsoft Office and Skype for Business

Microsoft sure is good at making lots of products that attempt to DoS its own customers websites. These requests are always POST requests, often to your homepage, and you require partial string matching to match the user agent, as it changes with the version of Office/Skype you are running.

In large organisation, I have seen the number of requests here number in the hundreds of thousands per day.

description: 'Microsoft Office/Skype for Business POST requests'
action: block
filter:
  expression: '(http.request.method eq "POST") and (http.user_agent matches "Microsoft Office" or http.user_agent matches "Skype for Business")'

Microsoft ActiveSync

Yet another Microsoft product that you don't why it is trying to hit another magic endpoint that doesn't exist.

description: 'Microsoft Active Sync'
action: block
filter:
  expression: '(http.request.uri.path eq "/Microsoft-Server-ActiveSync")'

Using the Cloudflare API to import custom WAF rules

It can be a pain to have to manually point and click a few hundred times per zone to import the above rules. Instead you would be better off to use the API. Here is a sample cURL command you can use do import all of the above rules in one easy go.

You will need to replace the redacted sections with your details.

curl 'https://api.cloudflare.com/client/v4/zones/XXXXXXXXXXXXXX/firewall/rules' \
  -H 'X-Auth-Email: XXXXXXXXXXXXXX' \
  -H 'X-Auth-Key: XXXXXXXXXXXXXX'
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json'
  -H 'Accept-Encoding: gzip'
  -X POST \
  -d '[{"ref":"","description":"Autodiscover","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path matches \"\/autodiscover\\.xml$\") or (http.request.uri.path matches \"\/autodiscover\\.src\/\")"}},{"ref":"","description":"Drupal 7 Unfriendly URLs (bots)","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.query matches \"q=user\/register\") or (http.request.uri.query matches \"q=node\/add\")"}},{"ref":"","description":"Install script","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path eq \"\/core\/install.php\")"}},{"ref":"","description":"Microsoft Active Sync","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path eq \"\/Microsoft-Server-ActiveSync\")"}},{"ref":"","description":"Microsoft Office\/Skype for Business POST requests","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.method eq \"POST\") and (http.user_agent matches \"Microsoft Office\" or http.user_agent matches \"Skype for Business\")"}},{"ref":"","description":"SQLi in URL","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path contains \"select unhex\") or (http.request.uri.path contains \"select name_const\") or (http.request.uri.path contains \"unhex(hex(version()))\") or (http.request.uri.path contains \"union select\") or (http.request.uri.path contains \"select concat\")"}},{"ref":"","description":"Wordpress common folders (excluding content)","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path matches \"\/wp-(admin|includes|json)\/\")"}},{"ref":"","description":"Wordpress content folder","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path matches \"\/wp-content\/\")"}},{"ref":"","description":"Wordpress PHP scripts","paused":false,"action":"block","priority":null,"filter":{"expression":"(http.request.uri.path matches \"\/wp-.*\\.php$\")"}}]'

How do you know the above rules are working

Visit the firewall overview tab in Cloudflare's UI to see how many requests are being intercepted by the above rules.

Cloudflare's firewall overview screen showing the custom WAF rules in action

Final thoughts

The above custom WAF rules are likely not the only custom WAF rules you will need for any given Drupal site, but it should at least be a good start. Let me know in the comments if you have any custom WAF rules that you always deploy. I would be keen to update this blog post with additional rules from the community.

This is likely the first post in a series of blog posts on customising Cloudflare to suit your Drupal site. If you want to stay up to date - subscribe to the RSS feed, sign up for email updates, or follow us on Twitter.

Jun 23 2019
Jun 23

APIGEE recently announced - from May 31, 2020, Apigee-sponsored hosting for Drupal-based portals will end. The existing customers who wish to remain on Drupal 7 need to assume hosting responsibility, they can either migrate to Drupal 8 or move to Apigee's integrated portal.

 

Those who wish to stick to Drupal 7 developer portals might possibly face challenges. But if Drupal has many security features and remains as one of the most secure Content Management System (CMS), what could possibly be the urgency to migrate?

What are the concerns?

Drupal 7 End-of-Life is Near

The developer portal is essentially a CMS, in case of APIGEE, based on Drupal. As the backend CMS, Drupal provides a core set of features in the form of modules that make it easy for you to build the content, as well as manage, websites.

Developer portals orchestrate API ecosystem which helps developers and external partners to quickly and securely gain access to the tools and information they need to explore, test, & consume APIs.

Apigee supports several developer portal solutions, ranging from simple turn-key to fully customizable and extensible, most if not all were built on Drupal 7. With community focus shifting to Drupal 9 release and end of life approaching for Drupal 7 (November 2021), among other circumstances Apigee will no longer be supporting the D7 developer portals.

With APIGEE support ending in May 2020, Drupal 7 developer portals will face the following security challenge.

 

Drupal 7 Can Put your Developer Portal at Risk


While Drupal also has many security features, security is not about working in isolation.  If one is to secure their digital property from the possible threats, it needs to follow best practices to maintain the top-notch standards.

One of the most important is keeping the core updated.

If you fall a long way behind the latest update, you are opening yourself to vulnerabilities. Let’s know in detail how Drupal 7 can put your developer portal at risk.

1. Doesn’t prevent cross-site scripting

Cross-site scripting (XSS) is a class of code vulnerabilities that allows code to be executed inside your browser without your consent or knowledge. XSS exploits are commonly performed with JavaScript, but Flash, Java, and other similar web programming technologies have been used.

It is one of the most frequent security vulnerabilities, a site owner should be aware of. It can be introduced in custom themes and custom-and-contributed modules. A poorly configured site can allow a malicious visitor to use XSS to change a user's password. Out of the box, Drupal 7 isn’t very effective to identify and fix XSS vulnerabilities.

In Drupal 7, elements like Drupal variables or Ctools exportables are represented as PHP code. This use of PHP input format in the core exposes possible code execution to vulnerability.

Drupal 8, however, filters the PHP input format in the core, manages code in a revision control system like GIT, and protects the code from any possible attack. Configuration Management Initiative uses YAML as the export and import format. YAML files are easy to manage together with your code and is a best practice to check it into a revision control system (like GIT).

2. Exposing session cookies

Drupal 7 stores the session ID and checks directly against the incoming session cookie from the browser. This poses a huge risk as the value from the database could populate the cookie in the browser assuming the session as well as the identity of any user who has had a valid session in the database.

On the other hand, Drupal 8 secures the session IDs against exposures via database backups or SQL injection, encourages serving your entire site via secure channel SSL and no longer strips the www from the session cookie domain.

3. No Automated CSRF token protection in route definitions

Cross-site request forgery (CSRF or XSRF) is a process where a request is made to a site which takes an action when the user did not intend to take that action.

GET requests with configuration change are not protected from CSRF in Drupal 7. This brings all the secure and unsecured requests under the scanner.  However, Drupal 8 makes it easy to specify a route (or system path) require a CSRF token.

4. No Clickjacking Protection

Drupal 7 cannot protect a site from click-jacking attacks wherein forms or links on the site are presented in a disguised fashion on an attacker's site inside an iframe. It cannot block the unauthorized re-use of site content via iframes too. However, Drupal 8 does this easily by sending the X-Frame-Options: SAMEORIGIN header in all responses by default. This header is respected by most browsers and prevents the site from being served inside an iframe on another domain.

Should you Migrate your Developer Portal to Drupal 8?

When choosing a solution, you need to balance your customization requirements against the time and knowledge required to implement your portal. Migrating your developer portal to Drupal 8 will ensure that any investments you make will extend the security of your digital presence.

Have doubts around your API security or want to migrate to Drupal 8 developer portal? Get in touch with our experts. We provide a range of services around API designed with a strategy tailored to your success.

May 21 2019
May 21

To keep up with consumer demand, businesses need to tactically rethink and reform the way they produce and manage content. 

What you need is a way to stand out in the consistent content chaos. To make that happen, you need a strategy that can help:

  • push out content intuitively
  • transform disorganized assets into a comprehensive manner
  • manage real-time collaboration effectively

And that’s where the role of a CMS is important.

Here’s a comprehensive guide to building the right content strategy with Drupal, focusing primarily on the technological aspect, which will help you build and establish the right notes with your audience.

You Need to Have a Content Strategy. But Why?

With an increase in the number of content dissemination channels, it is easy to lose consistency and easier to lose track of the larger goal.

“Pushing out content without being focused on the goal, its relevance, distribution, or the target audience is a waste of time and money – even if your content is amazing!”

The 2018 Demand Gen Report revealed that buyers are becoming more discerning and selective in the content they decide to consume. 88% agree that content producers need to focus less on product specifics and more on the value that can be brought to their business.

Infographic with three hexagons and text on it on a blue background

These key findings from the audience can be harnessed only with a well-designed content strategy. Which means by doing as little as creating a persona you get ahead of 58% of your competition (2018, CMI Report).

According to the same study, a whopping 97% of top performing B2B marketers have a content marketing strategy, while 32% of (overall) B2B marketers do not have a documented plan. In most cases, this means that they really have no clue what they’re doing.

Some of the benefits of a digital content strategy are:

  • Aligns your team with the organization’s mission/goals
  • Helps you figure out which types of content to develop and which will work
  • Keeps your team focused on priorities
  • Helps you allocate resources for better results
  • Clarifies your target audience/s

Building Content Strategy With Drupal

Traditionally, the content strategy involves planning, creation, and governance of content. However, with an explosion of channels and proliferation of new devices, content strategy can not be limited to just website content.

One of the challenges is to remain engaging yet relevant on different channels.

This can be solved by bringing uniformity and consistency across the various touch points from which a user can access information and engage with the content.

“The goal of the content strategy must be to strategically fit the reader into the marketing funnel”

Drupal’s dynamic features at the core make it a perfect fit to cater to the needs of creating great digital experiences. Here’s how:

Unifying the Content Strategy Across Channels with Drupal

Content Governance

Often neglected, content governance is a detailed framework of content delivery and management which ensures consistent brand storytelling across all media.

Implementing a content governance framework requires different users (from the same or different teams) to collaborate with a distinct workflow and audit trail effectively. In the face of exponential growth in the variety and volume of content,  Drupal helps manage, organize, and secure the content with Workflow and Staging. 

Since editing the content on live site can also result in accidental publishing, Drupal’s Workflow module provides a separate staging environment . Drupal has an easy staging and preview of content in different environments anchoring full content staging capabilities.

You can define multiple workspaces such as "staging" and "live" which are copies of your site, to create content (or modify) and the changes are visible only within that workspace. Once the changes have been verified, you can "deploy" the content to another workspace.

User, roles, and permission: Security is important and that is why not every user can have permission to access the system of the website. Drupal offers a number of security modules which help manage and secure backend access. 

With User Access Control, site administrators on Drupal can work to provide unique user experiences and different access rights to writers, editors, marketers, and site visitors.

The Workflow module helps in creating arbitrary workflows and assigning them to entities. That's  important from a security perspective too. Workflow with the states like Draft, Review and Published can be assigned to Story node type.

Thus, only the users with ‘Editor’ permissions can set stories to the published state.

Some of the other Drupal modules which can be used are:

  • Workbench Access module: helps in creating editorial access control. Admin can grant access to the users and their content which can be found at My Workbench on Homepage. It harnesses content-focused features in one unified user interface.
  • Domain Access module: allows you to share users, content, and configurations across a group of sites.

Enterprise-wide password control systems

Password security is even more crucial and needs the right kind of strategic perspective with strong policies.Default password management could be considered good, but of course, it can be improved. Here’re some of the Drupal security modules that can be used to provide additional controls for password management:

  1. Password Strength: provides realistic password strength measurement and server-side enforcement for Drupal sites using pattern-matching and entropy calculation.
  2. Password Policy: provides a way to enforce constraints which must be met before a user password change will be accepted.
  3. Restrict Password Change: Adds a new permission 'change other users password'. When the user_profile_form is loaded it checks to see if the current user has the proper permission or if they are editing their own account, otherwise, it removes the password change option.
  4. Login Security: Login Security module improves the security options in the login operation of a Drupal site. By default, Drupal introduces only basic access control denying IP access to the full content of the site.
  5. Shibboleth Authentication: Provides user authentication as well as some authorisation features.
  6. Flood Control: Add an administration interface for hidden flood control variables in Drupal 7, like the login attempt limiters and future hidden variables.
  7. Secure Login: Ensures that the user login and other forms are submitted securely via HTTPS, thus preventing passwords and other private user data from being transmitted in the clear.

Digital Asset Management System: An important part of the governance is business workflow and common identity, which is significant for the smooth functioning of marketing. The CMS needs to provide the ability as a solid repository while also able to modify uploaded digital assets.

It should give editors the ability to make iterative changes to assets to enable promotion of products and brand across channels and devices. Digital Asset Management (DAM) smartly strategizes the way enterprises handle their digital assets.

The Acquia DAM Connector can sync your digital assets with your Drupal website, allowing editors to seamlessly use content from within all the websites you maintain. In order to ensure that the site is using the latest version of an asset stored, it periodically syncs assets from Acquia DAM via a cron job.

It also empowers editors to select Acquia DAM assets directly through a media field or through the WYSIWYG integration. Further, it enables the user to view asset metadata directly in the entity browser without importing the asset and provides a usage report of assets within Drupal.

“In the digital landscape, the creation of digital assets in large numbers is almost inevitable.”

Backup: Writing content is an intensive exercise. And so you need to have a backup to save yourself in case the website system crashes or is hacked.

Backup and Migrate: Back up and restore your Drupal MySQL database, code, and files or migrate a site between environments. Backup and Migrate supports gzip, bzip and zip compression as well as automatic scheduled backups.

Content Modelling with Drupal

Before you start building the site it is important to consider your content as a whole and work out a model that will guide you and the user to smoothly navigate through the website.

It entails detailed definitions of each content type’s elements and their relationships to each other. It also helps to identify the organization’s requirements, develop relevant taxonomy that meets those requirements, and consider where the content blocks and fields should be allowed or required. 

Content modelling is a critical starting point for website content.

Drupal is an incredible CMS for building a content-rich website. Built on its entity system and the variety of field types, Drupal can support a wide range of content models.

At core, it is built on View which can help sort out the default taxonomy/term view however you want. Let’s you want a way to display a block with the X most recent posts of some particular type.

It can be used for anything that handles the display of views, and the core Views UI module permits you to create and edit them in the administrative interface. When you define views, you are interested in taking data from your website and displaying it to the user.

Breaking content types into fields, it allows you to build structured content as well.

Modules like Paragraphs and Stacks let you build rich and dynamic content.

Layout Builder, a stabilized module, in Drupal 8.7, empowers you to build layouts with ready-to-use multi-column layouts and Drupal blocks without the intervention of a developer.

It is unique since it can support multiple and different use cases from templated layouts applied to dozens of pieces of structured content, to designing custom one-off pages with unstructured content.

Here’s how it can be used in three different use cases:

  1. Layouts for templated content: The creation of ‘layout templates’ can be used for a specific content type. Example, blog posts.
  2. Customizations to templated layouts: Can customize the layout templates on a case-by-case basis. Example, to override the layout of a standardized product page.
  3. Custom pages: The creation of custom landing pages which are not in sync to any particular content type or structured content. Example, a single ‘About us’ page.

The Layout Builder is more powerful when used with Drupal's other out-of-the-box features such as revisioning, content moderation, and translations.

Omnichannel Content Strategy with Drupal

Users are always at the centre. Therefore, the content strategy needs to be as dynamic as your user experiences across different channels, if it is to succeed. Omnichannel content strategy is a way to unify the experience across all the channels and touchpoints.

Irrespective of how and where the content/ products are being first consumed at, complete consistency and unified experience is expected.

API First Publishing with Drupal

Drupal 8 is API-first which means, it can power ambitious applications of all kinds, from behind-the-scenes systems written in languages like Python, Java or Go to rendered experiences using the latest frontend frameworks, like React, Vue and Ember.

Content touchpoints are proliferating at a fast clip. You now have conversational UI, digital signage, medical and healthcare devices, and it lets you integrate with other systems, use your content anywhere, display it as you please. API-First Drupal is well positioned for entire digital ecosystems.

[embedded content]

The JSON:API module, which is also now in core with Drupal 8.7, is meant for creating high-performance APIs to expose Drupal data in JSON. It works by creating API endpoints and requires no configuration and the module instantly accesses all Drupal entities.

It not only provides a great authoring experience but also a powerful, standards-compliant, web service API to pull that content into JavaScript applications, digital kiosks, chatbots, voice assistants and more.

This makes it easier for Drupal’s core ecosystem, of web services responsible for third-party content and application, to integrate.

Mobile-first and Out of the Box Responsive

Accessibility via any device needs to be useable too. Drupal 8 has been designed with a mobile-first strategy. The responsive design ensures that content and layout are scaled based on the viewport size available.

With  Breakpoint and Responsive Image, out-of-the-box Drupal 8 ships with two modules that ensure mobile-first behaviour .

Responsive content needs to be modular and readable so readers can easily consume it.

Drupal for mobile lets you easily define different pieces of content for different devices. Each field in the backend can be uniquely styled and prioritized according to its content type.

Personalization with Drupal

No matter how good your content is, no one will bother to read it if it doesn’t talk to them, in their own language. Every content piece needs to communicate with your audience and increase the relevance of product proposition, by addressing their unique fears, needs and desires.

This orchestrates customer experience and drive engagement.

Personalization brings familiarity, which brings strength to customer loyalty to your brand, helps track demographics and behavioural patterns and convert an anonymous user into a potential customer.

Acquia Lift solves the challenges for digital teams, by bringing together content and user profile data from any source to personalize the customer journey in ways not previously possible. More than a headline swap or banner choice, Lift presents wholly targeted experiences based on broadly observed visitor behaviors as well as specific user preferences and interactions in real time with the very first engagement across any device or channel.

“And 81% of B2B Marketers (2018, CMI Report) believe that building a content strategy makes it easier to determine which types of content to develop.”

Drupal in Other Marketing Technology

New technologies like artificial intelligence (AI), machine learning, Augmented Reality (AR), Virtual Reality (VR) among others are reshaping how users consume content. It’s a big opportunity for companies to produce and recycle the same content through different channels and mediums. All the while keeping people engaged.

Virtual Reality

Immersive experiences created by virtual reality is the “Next Big Thing” happening. Virtual reality has seen a surge lately, with constantly emerging in Gartner Hype Cycle. While it is rapidly approaching a much more mature stage, in the enterprise sector, virtual reality has already lots of scenarios where it gets employed with success.

For instance, educational purposes. VR can enable a lot of more experiences that in reality are not possible or too dangerous.

Here’s a demo video of a high school student, Jordan who explores Massachusetts State University (a fictional university, built on Drupal) from the comfort of his couch. Jordan is able to take a virtual tour directly from the university's website.

[embedded content]

 
Augmented Reality

Another part of the futuristic technology, AR can be used to superimpose useful information in a shopping experience.

[embedded content]


The demonstration shown in this video displayed a shopper interacting with the AR application. The mobile application of Freshland Market (a fictional grocery store), built on Drupal 8, guided the shopper through her shopping list.

Wrapping Up

Often, it can be a virtual nightmare for content producers and marketers trying to find the right piece at the right time. Even so, if the content is all in one place, time-consuming complicated systems can mess up really bad.

Drupal 8 provides a perfect foundation for the incorporation of technologies to enable a smart strategy for your brand, content, and digital marketing needs. Your organization might be at infancy or already up with your content strategy, you can always reach out to our experts who can help you deliver quality results with personalized experiences.

Aug 30 2018
Aug 30

Pelo Fitness spinning class

Pelo Fitness spinning class

One of the best things about Drupal is its security. When tens of thousands of developers work collectively on an open source project, they find all the holes and gaps, and strive to fix them. When one is found, patches go out immediately to keep sites safe and secure. But a site is only secure if those patches are applied when they are released.

Pelo Fitness is a Marin County-based community dedicated to a culture of fitness. They offer cycling, strength, yoga & nutrition programs customized to an individual’s needs and fitness level. Whether someone is a competitive athlete, a busy executive or a soccer mom (or perhaps all three), their programs are designed to build strength and endurance, burn calories and boost energy.

Yet their site was weak since they hadn’t applied a few major Drupal security updates. There was a concern that the site could be hacked and jeopardize client information. Pelo Fitness customers use the site to purchase class credits and reserve bikes for upcoming classes, requiring users to log in and enter personal information.

Want to keep your site secure? Contact us to get started. 

The solution

Kanopi performed all the security updates to get the Pelo Fitness on the latest version of Drupal. All out of date modules were updated, and the site was scanned for suspicious folders and code; anything that looked suspect was fixed. Care was taken not to push code during high traffic times when reservations were being made, so code was pushed live during specific break times that would allow for the least disruption. Lastly the site was also moved over to Pantheon for managed hosting.

Due to the Drupal support provided by Kanopi, the Pelo Fitness website is now protected and secure. Inspired to make all their systems stronger, Pelo Fitness also switched to a different email system as well so all their tech solutions were more up to date.

How to keep your site secure

Websites are living organisms in their way, and need constant care and feeding. It’s imperative to always apply critical security patches when they come out so your users information (and your own) is kept secure at all times. There are a few simple things that you can do on your Drupal site to minimize your chances of being hacked.

  • Stay up to date! Just like Pelo Fitness, make sure you pay attention to security updates for both Drupal core and your contributed modules. Security releases always happen on Wednesdays so it’s easy to keep an eye out for them. To stay up to date, you can subscribe via email or RSS on Drupal.org or follow @drupalsecurity on Twitter.
  • Enable two-factor authentication on your site. It’s a few seconds of pain for an exponential increase in security. This is easily one of the best ways to increase the security of your site. And besides, it helps you makes sure you always know where your phone is. The TFA module provides a pluggable architecture for using the authentication platform of your choice, and Google Authenticator integration is available already as part of their basic functionality.
  • Require strong passwords. Your site is only as secure as the people who log into it. If everyone uses their pet’s name as their password, you can be in trouble even if your code base is “bulletproof” (nothing ever is). The Password Policy module sets the gold standard for traditional password strength requirements, or you can check out the Password Strength module if XKCD-style entropy is more your thing.
  • Make sure you’re running over a secured connection. If you don’t already have an SSL (TLS, technically, but that’s another story) certificate on your website, now is the time! Not sure? If your site loads using http:// instead of https://, then you don’t have one. An SSL certificate protects your users’ activities on the site (both site visitors and administrators) from being intercepted by potential hackers.
  • Encrypt sensitive information. If the unthinkable happens and someone gets hold of your data, encryption is the next line of defense. If you’re storing personally identifying information (PII) like email addresses, you can encrypt that data from the field level on up to the whole database. The Encrypt module serves as the foundation for this functionality; check out the module page and you can build up from there.
  • Don’t let administrators use PHP in your content. Seriously. The PHP filter module can get the job done quickly, but it’s incredibly dangerous to the security of your site. Think seriously about including JavaScript this way, too. If your staff can do it, so can a hacker.
  • Think about your infrastructure. The more sites you run on a single server, the less secure it is. And if Drupal is up to date, but your server operating system and software isn’t, you still have problems. Use web application and IP firewalls to take your security even further. 

Contact us at Kanopi if you need help keeping your site secure.

Mar 02 2018
Mar 02

Happy Friday Everyone! On the eve of the Drupal Drive-in, happening tomorrow in Charlotte North Carolina, we welcome Mark Shropshire to the show to talk about his favorite topic, Drupal Security!

Jan 18 2018
Jan 18
January 18th, 2018

What are Spectre and Meltdown?

Have you noticed your servers or desktops are running slower than usual? Spectre and Meltdown can affect most devices we use daily. Cloud servers, desktops, laptops, and mobile devices. For more details go to: https://meltdownattack.com/

How does this affect performance?

We finally have some answers to how this is going to affect us. After Pantheon patched their servers they released an article showing the 10-30% negative performance impact that servers are going to have. For the whole article visit: https://status.pantheon.io/incidents/x9dmhz368xfz

I can say that I personally have noticed my laptop’s CPU is running at much higher percentages than before the update for similar tasks.
Security patches are still being released for many operating systems, but traditional desktop OSs appear to have been covered now. If you haven’t already, make sure your OS is up to date. Don’t forget to update the OS on your phone.

Next Steps?

So what can we do in the Drupal world? First, you should follow up with your hosting provider and verify they have patched your servers. Then you need to find ways to counteract the performance loss. If you are interested in performance recommendations, Four Kitchens offers both frontend and backend performance audits.

As a quick win, if you haven’t already, upgrade to PHP7 which should give you a performance boost around 30-50% on PHP processes. Now that you are more informed about what Spectre and Meltdown are, help with the performance effort by volunteering or sponsoring a developer on January 27, 2018 and January 28, 2018 for the Drupal Global Sprint Weekend 2018, specifically on performance related issues: https://groups.drupal.org/node/517797

Web Chef Chris Martin
Chris Martin

Chris Martin is a support engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Dec 22 2017
Dec 22

Website developers considering code.

Website developers considering code.

Now that you’ve considered your user experience, there are a number of possible technical fixes that might help resolve your website problems.

What version of Drupal or WordPress are you using?

  • WordPress 2, while old, may or may not require a rebuild. You might be able to get by with updating and refactoring.
  • If you’re using Drupal 7 or WordPress 3, a rebuild is likely not needed. 
  • However, if you are on Drupal 6, it is at the end of its life, which may make rebuilding more cost-effective and viable for the long term.

Does your site use a lot of custom code?

If so, what does that code do, and are you still using that functionality? Look for ways to streamline where possible.

Is your site’s code a nightmare?

Did you use a professional firm with a North American team? An offshore team? A freelance developer? Or an internal employee who no longer works at your company? It’s a good idea to get the code reviewed so that you can determine its quality and understand whether it will be easy to update or if you’d be better off starting from scratch. Contact Kanopi for a low-cost assessment.

Are you up to date with the latest security patches and updates?

Lapses can expose the site to hacks and backdoors. Often just updating your site and modules/plugins can solve many issues.

Want to learn more about how we can help you understand every aspect of your site and determine if you need to rebuild or update to help achieve your goals? Contact us to book a free 15-minute consultation. Click here to book a time.

Jul 25 2017
Jul 25

This is an example of anti-virus implementation with an Ubuntu server.

Our back office management solution allows users to upload files in various sections of the application for storage or file sharing. For this reason, checking of files for virus is an important advantage.

We use the ClamAV module integration from Drupal 8.

1) Install ClamAV on Ubuntu

Installation on Ubuntu server is straight forward.  However, it is better to install with clamav-daemon clamav-freshclam options for later settings

You can test with clamscan -r /home for instance

For further options you may refer to ClamAV website.

2) Install and set-up Drupal module

Module installation on Drupal 8 has no specific requirements.

As indicated on the module page, "Daemon mode" is preferred when executing the scan.

In the settings page (/admin/config/media/clamav), select Daemon mode (over Unix socket) in scan mechanism

You need to indicate the path for the socket pointing file; it can be found in the configuration file  : /etc/clamav/clamd.conf.

Input the file path into next setting:

3) Test

When uploading a file on the server via any upload interface, the file is scanned and validated. Scanning process is logged:

The Eicar test virus file is filtered when uploaded:

If you have implemented ClamAV with Drupal and have further comments, please feel free input your own.

Thank you.

Dec 01 2016
Dec 01

dec16The twelfth issue of 2016 is now available! This month we look at how to write good tests with Behat and using Test Driven Development. This issue also includes articles on using HTTPlug to decouple your HTTP Client, Decoupled Blocks with Drupal and JavaScript. Our columnists have articles on writing a Chat bot, advice on securing your application’s secrets, making better bug reports, respecting diversity, and a look back at 2016.

Download your issue and read a FREE article today.

Oscar still remembers downloading an early version of the Apache HTTP server at the end of 1995, and promptly asking "Ok, what's this good for?" He started learning PHP in 2000 and hasn't stopped since. He's worked with Drupal, WordPress, Zend Framework, and bespoke PHP, to name a few. Follow him on Google+.
Aug 10 2016
Aug 10

So your site has been hacked ? Or more likely you wonder what to do when it eventually happens : the video for my "Life after the hack" is now available. From initial diagnosis to return online, with a healthy dose of forensics along the way. [embedded content]

The slides are also available for easier access, but of course absent the extra speaker comments :

Initially designed for the Drupalcon Dublin audience, it was given earlier at the DevDays Milan in june, so you may have missed it, due to the smaller audience at DevDays.

Jul 13 2016
Jul 13

The Drupal security team published a PSA to warn about upcoming security advisories. I shared my advice and predicted attacks within the hour after the security advisories are published. The security advisories are now published. Here is my followup.

I applaud the Drupal Security Team for warning about the highly critical updates. However the public service announcement (PSA) left the impression that this event was going to be much more serious than it was. Such a PSA would have been perfectly appropriate for SA-CORE-2014-005 "Drupalgeddon". But the only PSA there was in hindsight.

I guess it is resonable for the Drupal Security Team to be over cautious, especially given the lessons learned from Drupalgeddon fallout. And of course, such decisions and criticism is much easier with hindsight.

But now I am concerned how the Drupal Security Team can realistically raise the level further there is another vulnerability that is as serious as Drupalgeddon. Even if they raise the alert level using language in the PSA, will people still believe them? It reminds me of the boy who cried wolf.

Of course serious vulnerabilities like these are rare events in Drupal, so there is not yet a standard to compare alert levels to.

Jul 12 2016
Jul 12

Just arrived here? Read my followup first.

Original post

The Drupal security team announced multiple highly critical updates to Drupal contrib modules in PSA-2016-001. Expect attacks within less than one hour from the announcement; 18 hours from the time this article is published. This is probably going to be Drupalgeddon all over again.

My advice

If you are prepared, you will save yourself a lot of time. If you are late or too slow, you will probably find yourself with a lot more work, e.g. the rescue workflow for Drupalgeddon 1.

Today

Don't skimp on the first two. And do at least one of "3. Update a contrib module" or "4. Learn how to apply patches". Which one you choose depends on your skills and how out of date contrib modules are on your Drupal websites. Ideally, do both steps 3 & 4; You might find one of them is significantly challenging for you.

  1. Backup your Drupal 7 websites; Database, code & files directory
  2. Plan to be online at 1600 Wednesday 13 July 2016 UTC. In other timezones:
    America/Los_Angeles: 0900 Wednesday 13 Jul
    America/New_York: 1200 Wednesday 13 Jul
    Europe/London: 1700 Wednesday 13 Jul
    Europe/Paris: 1800 Wednesday 13 Jul
    Australia/Sydney: 0200 Thursday 14 Jul
    Pacific/Auckland: 0400 Thursday 14 Jul
  3. Update a contrib module on each of your Drupal 7 website(s) to make sure there will be no problems and you know how to do it. Do it manually by downloading the module from Drupal.org. The update server that Drush and Drupal use might be delayed, overloaded or under attack.
  4. Learn how to apply patches:
    1. Choose any popular module that your website uses, e.g. Views
    2. Navigate to the module's issue queue
    3. Filter for "Reviewed & tested by the community"
    4. Filter for the version of the module your website uses
    5. E.g. Views 7.3 RTBC issues
    6. Open any issue
    7. Download any .patch file
    8. Apply it using Drupal's documentation, which boils down to something like:
      1. cd sites/all/modules/views/
      2. patch -p1 < ~/Downloads/views-fix_hide_rewriting_if_empty-1428256-21.patch
      3. Test the patched module still works
  5. Restore your website from the backup into a new environment to make sure your backup is complete, you have sufficient access and you know how to do it. If you are on time and fast, this won't become necessary. But just in case...
  6. Subscribe to Drupal security email announcements: Log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the "Edit » My newsletters" tab.
  7. Consider taking servers that host highly sensitive data offline if your Drupal website can reach them. Drupal's maintenance mode may not be sufficient protection.
  8. If you can move to a Drupal-tailored web host easily, do so. They often offer additional protection while you work on applying updates. I usually recommend Pantheon.
  9. Take stock of any modifications (patches) to Drupal core and contrib modules. The Hacked! module automates most of this.
  10. Clean up and/or take stock of any unusual files in your website. A version control system like git makes this easy.
  11. Use the Security Review module to check if you have configured your Drupal website securely.
  12. Backup your website again if you made changes since the last backup.
  13. Subscribe to my blog;
    • I will post any important or relevant updates, more aggressively than what the Drupal Security Team is able to
    • Submit your email address in the right sidebar.
    • You can unsubscribe anytime (I won't be offended)

At T minus 1-hour

At 1500 Wednesday 13 July 2016 UTC, an hour before the scheduled time;

Do what you need to do to have the next few hours free from distractions; I.e. eat, use the bathroom, get comfortable.

At 1600 Wednesday 13 July 2016 UTC

  1. Look for contrib security advisories on Drupal.org.
  2. For each advisory that is published, check if your website(s) use the module. If yes, update it.
  3. Check you are recieving security advisory emails. Sometimes the highly critical updates require followup.

Drupal 6

The Drupal security team no longer supports Drupal 6. So we don't yet know if it is vulnerable or if there will be a patch. All of the above applies and you should do it, but if Drupal 6 is vulnerable patches or updates will probably be provided by the Drupal 6 long term support (LTS) programme.

Worst case, be prepared to roll-back to your backup from before the announcement.

Consider also;

  1. Accellerating your plans to upgrade to Drupal 7 or 8
  2. Taking your server or website offline
  3. Archiving it as a static HTML website (no PHP)
  4. Maintenance mode or locked-down permissions to be read-only is better than nothing, but may not offer any protection

Will I be affected?

The Drupal security team have added that the affected contrib modules are used on between 1,000 and 10,000 sites. That limits the affected modules to those ranked 522 to 2180; Just 1680 of the most popular 2000 Drupal contrib modules. Some Drupal websites, especially simple ones, will be lucky in that they won't be using an affected contrib module. But don't count on luck.

May 18 2016
May 18
teaser image for blog post

In this blog post I'll discuss some methods of ensuring that your software is kept up to date, and some recent examples of why you should consider security to be among your top priorities instead of viewing it as an inconvenience or hassle.

Critics often attack the stability and security of Open Source due to the frequent releases and updates as projects evolve through constant contributions to their code from the community. They claim that open source requires too many patches to stay secure, and too much maintenance as a result.

This is easily countered with the explanation that by having so many individuals working with the source code of these projects, and so many eyes on them, potential vulnerabilities and bugs are uncovered much faster than with programs built on proprietary code. It is difficult for maintainers to ignore or delay the release of updates and patches with so much public pressure and visibility, and this should be seen as a positive thing.

The reality is that achieving a secure open source infrastructure and application environment requires much the same approach as with commercial software. The same principles apply, with only the implementation details differing. The most prominent difference is the transparency that exists with open source software.

Making Headlines

Open Source software often makes headlines when it is blamed for security breaches or data loss. The most recent high profile example would be the Mossack Fonseca “Panama Papers” breach, which was blamed on either WordPress or Drupal. It would be more accurate to blame the firm itself for having poor security practices, including severely outdated software throughout the company and a lack of even basic encryption.

Mossack Fonseca were using an outdated version of Drupal: 7.23. This version was released on 8 Aug 2013, almost 3 years ago as of the time of writing. That version has at least 25 known vulnerabilities. Several of these are incredibly serious, and were responsible for the infamous “Drupalgeddon” event which led to many sites being remotely exploited. Drupal.org warned users that “anyone running anything below version 7.32 within seven hours of its release should have assumed they’d been hacked”.

Protection by Automation

Probably the most effective way to keep your software updated is to automate and enforce the process. Don’t leave it in the hands of users or clients to apply or approve updates. The complexity of this will vary depending on what you need to update, and how, but it can often be as simple as enabling the built-in automatic updates that your software may already provide, or scheduling a daily command to apply any outstanding updates.

Once you've got it automated (the easy part) you will want to think about testing these changes before they hit production systems. Depending on the impact of the security exploits that you're patching, it may be more important to install updates even without complete testing; a broken site is often better than a vulnerable site! You may not have an automated way of testing every payment permutation on a large e-commerce site, for example, but that should not dissuade you from applying a critical update that exposes credit card data. Just be sure you aren't using this rationale as an excuse to avoid implementing automated testing.

The simple way

As a very common example of how simple the application of high priority updates can be, most Linux distributions will have a tried and tested method of automatically deploying security updates through their package management systems. For example, Ubuntu/Debian have the unattended-upgrades package, and Redhat-based systems have yum-cron. At the very least you will be able to schedule the system’s package manager to perform nightly updates yourself. This will cover the OS itself as well as any officially supported software that you have installed through the package manager. This means that you probably already have a reliable method of updating 95% of the open source software that you're using with minimal effort, and potentially any third-party software if you're installing from a compatible software repository. Consult the documentation for your Linux distro (or Google!) to find out how to enable this, and you can ensure that you are applying updates as soon as they are made available.

The complex way

For larger or more complex infrastructure where you may be using configuration management software (such as Ansible, Chef, or Puppet) to enforce state and install packages, you have more options. Config management software will allow you to apply updates to your test systems first, and report back on any immediate issues applying these updates. If a service fails to restart, a service does not respond on the expected port after the upgrade, or anything goes wrong, this should be enough to stop these changes reaching production until the situation is resolved. This is the same process that you should already be following for all config changes or package upgrades, so no special measures should be necessary.

The decision to make security updates a separate scheduled task, or to implement them directly in your config management process will depend on the implementation, and it would be impossible to cover every possible method here.

Risk Management

Automatically upgrading software packages on production systems is not without risks. Many of these can be mitigated with a good workflow for applying changes (of any kind) to your servers, and confidence can be added with automated testing.

Risks

  • You need to have backups of your configuration files, or be enforcing them with config management software. You may lose custom configuration files if they are not flagged correctly in the package, or the package manager does not behave how you expect when updating the software.
  • Changes to base packages like openssl, the kernel, or system libraries can have an unexpected effect on many other packages.
  • There may be bugs or regressions in the new version. Performance may be degraded.
  • Automatic updates may not complete the entire process needed to make the system secure. For example, a kernel update will generally require a reboot, or multiple services may need to be restarted. If this does not happen as part of the process, you may still be running unsafe versions of the software despite installing upgrades.

Reasons to apply updates automatically

  • The server is not critical and occasional unplanned outages are acceptable.
  • You are unlikely to apply updates manually to this server.
  • You have a way to recover the machine if remote access via SSH becomes unavailable.
  • You have full backups of any data on the machine, or no important data is stored on it.

Reasons to NOT apply updates automatically

  • The server provides a critical service and has no failover in place, and you cannot risk unplanned outages.
  • You have custom software installed manually, or complex version dependencies that may be broken during upgrades. This includes custom kernels or kernel modules.
  • You need to follow a strict change control process on this environment.

Reboot Often

Most update systems will also be able to automatically reboot for you if this is required (such as a kernel update), and you should not be afraid of this or delay it unless you're running a critical system. If you are running a critical system, you should already have a method of hot-patching the affected systems, performing rolling/staggered reboots behind a load-balancer, or some other cloud wizardry that does not interrupt service.

Decide on a maintenance window and schedule your update system to use it whenever a reboot is required. Have monitoring in place to alert you in the event of failures, and schedule reboots within business hours wherever possible.

Drupal and Other Web-based Applications

Most web-based CMS software such as Drupal and Wordpress offer automated updates, or at least notifications. Drupal security updates for both core and contributed modules can be applied by Drush, which can in turn be scheduled easily using cron or a task-runner like Jenkins. This may not be a solution if you follow anything but the most basic of deployment workflows and/or rely on a version control system such as Git for your development (which is where these updates should go, not direct to the web server). Having your production site automatically update itself will mean that it no longer matches what you deployed, nor what is in your version control repository, and it will be bypassing any CI/testing that you have in place. It is still an option worth considering if you lack all of these things or just want to guarantee that your public-facing site is getting patches as a priority over all else.

You could make this approach work by serving the Git repo as the document root, updating Drupal automatically (using Drush in 'security only' upgrade mode on cron), then committing those changes (which should not conflict with your custom code/modules) back to the repo. Not ideal, but better than having exploitable security holes on your live servers.

If your Linux distribution (or the CMS maintainers themselves) provide the web-based software as a package, and security updates are applied to it regularly, you may even consider using their version of the application. You can treat Drupal as just another piece of software in the stack, and the only thing that you're committing to version control and deploying to servers is any custom modules to be layered on top of the (presumably) secure version provided as part of the OS.

Some options that may fit better into the common CI/Git workflows might be:

  • Detect, apply, and test security patches off-site on a dedicated server or container. If successful, commit them back to version control to your dev/integration branch.
  • Check for security updates as part of your CI system. Apply, test and merge any updates into your integration branch.

Third-party Drupal Modules (contrib)

Due to the nature of contrib Drupal modules (ie, those provided by the community) it can be difficult to update them without also bringing in other changes, such as new features (and bugs!) that the author may have introduced since the version you are currently running. Best practice would be to try to keep all of the contrib that the site uses up to date where possible, and to treat this with the same care and testing as you would updates to Drupal itself. Contrib modules often receive important bug fixes and performance improvements that you may be missing out on if you only ever update in the event of a security announcements.

Summary

  • Ensure that updates are coming from a trusted and secure (SSL) source, such as your Linux distribution's packaging repositories or the official Git repositories for your software.
  • If you do not trust the security updates enough to apply them automatically, you should probably not be using the software in the first place.
  • Ensure that you are alerted in the event of any failures in your automation.
  • Subscribe to relevant security mailing lists, RSS feeds, and user groups for your software.
  • Prove to yourself and your customers that your update method is reliable.
  • Do not allow your users, client, or boss to postpone or delay security updates without an incredibly good reason.

You are putting your faith in the maintainer's' ability to provide timely updates that will not break your systems when applied. This is a risk you will have to take if you automate the process, but it can be mitigated through automated or manual testing.

Leave It All To Somebody Else

If all this feels like too much responsibility and hard work then it’s something Ixis have many years of experience in. We have dedicated infrastructure and application support teams to keep your systems secure and updated. Get in touch to see how we can ensure you're secure now and in the future whilst enjoying the use and benefits of open source software.

Apr 18 2016
Apr 18

In our last post we talked about how the Drupal Community is supporting Drupal 6 after its end-of-life and what that means for your Drupal 6 site.  In this post we’ll get a bit more technical and talk about what exactly you need to do to keep your website up to date.

Step #1: Getting an accurate report of your site’s modules and themes

Ever since the Drupal 6 sunset date, your website’s report of Available Updates at /admin/reports/updates has been telling you that everything is unsupported and should be uninstalled.  That’s not very helpful :-)

Drupal 6 Update module report

So the first step is to get the myDropWizard module.  This is provided free (libre) to the Drupal Community by one of the Drupal LTS vendors. The main purpose of this module is to show whether a module is supported by the Drupal 6 Long-Term Support (LTS) vendors, so you’ll know if it’ll be getting security updates going forward.

Drupal 6 MyDropWizard report

Ahhh, that’s better.

Now you can continue to manage security updates for modules and themes just like you always have.  But there are some significant gotchas.

How problems are found and fixed

When vulnerabilities are found they will be posted as issues in the Drupal 6 LTS project.  Once the issue is  fixed, and if the module maintainer is still maintaining the D6 version, then the maintainer will simply release a new version, just like normal.  But if the maintainer is no longer maintaining it, then new releases are made on Github.  Drupal Core is no longer receiving any new commits on the 6.x branch,  so new releases will be made to the Pressflow project, also on Github.

How to obtain new versions

If new releases are scattered across Drupal.org and Github, the question becomes: How do we easily obtain new versions?  Assuming that you run security updates with Drush, then you can use the --update-backend=mydropwizard flag when calling any of Drush’s Project Management commands (pm-download, pm-refresh, pm-updatedstatus).  The MyDropWizard backend will automatically obtain the project from Github or Drupal.org.

New Drush

But this brings a new problem: The --update-backend flag only works with Drush 7 or later.  On a server that’s running Drupal 6, chances are high that it’s using Drush 6, and chances are also high that it’s using an old version of PHP (like 5.3.3 that is bundled with Debian/Ubuntu).  The old version of PHP means that you can’t upgrade to the latest Drush 7 (7.2.0).  But there’s a fix on the way for that.

Switching to Pressflow?

Since new releases are no longer made to Drupal Core, and only to Pressflow, this creates a bit of a dilemma for sites that are not running Pressflow.  In those cases it’s probably more cost effective to manually apply patches rather than move to Pressflow.  There’s a couple ways to be notified of these commits:

Add-on modules

The final tricky area that we’ve found is with modules that extend Update Status module. There’s two in particular that we use often: Update Exclude Unsupported, and Update Status Advanced Settings — neither of these will work anymore.  Instead you’ll need to implement hook_mydropwizard_status_alter().

/**
 * Implements hook_mydropwizard_status_alter().
 */
function mymodule_security_mydropwizard_status_alter($projects) {

  // Projects determined to be okay for this particular site.
  $projects_deemed_okay = array(
    // This is okay because of the finglewabble.
    'foo', 
    // This is okay because of hard-coded site configuration. 
    'bar',
  );
  foreach ($projects_deemed_okay as $module) {
    if (isset($projects[$module])) {
      $projects[$module]['status'] = 'deemed-okay';
      $projects[$module]['extra'][] = array(
        'class' => 'deemed-okay',
        'label' => t('Deemed okay'),
        'data' => t('This project was analyzed and determined to be acceptable to run on your site.'
      );
    }
  }
}

Conclusion

I’m sure there will be a few more hiccups along the way, but this should get you started.

Image by: Henri Bergius

Apr 08 2016
Apr 08

Those of you who still have a Drupal 6 site are by now aware that you need to do something with it since this version is no longer supported.  Your options in short are:

  • Upgrade to Drupal 7
  • Upgrade to Drupal 8
  • Choose one of several options to limit your vulnerability (e.g. convert the site into a static HTML website, or close logins to all but a handful of trusted people and harden the security of the login form)

But that’s a big decision.  What do you do until you’ve decided which path to choose?  Now that Drupal 6 is past its sunset date, is your site suddenly vulnerable to having its data stolen and being turned into a spam factory?

The short answer

As long as you have someone keeping an eye on the security of your site, you’re just fine.  Take some time to make your decision — just don’t wait too long.

Interested in our Drupal security services?  Contact us to find out more.

The long answer

The long answer is a bit more nuanced.  When the Drupal 6 end-of-life was approaching, the Drupal Security Team asked for vendors to apply to become recognized as official Drupal 6 Long Term Service Vendors.  These LTS vendors have clients running Drupal 6 websites.  As security vulnerabilities are found and fixed in Drupal 7 (and Drupal 7 modules) the vendors are committing to make those same fixes to the Drupal 6 versions, but only for the modules that their clients are using.  

That exception has significance for other Drupal 6 sites and it all boils down to the question of:

How much security is enough?  

Low risk websites

Many (most?) websites only need to be worried about automated security attacks: Villains and mischief makers will try to attack every website on the Internet using every known vulnerability.  A tiny fraction  of the time they’ll be successful and turn a website into a spam factory, or virus spreader.  If they do their work well the site owner won’t even notice.  There’s a very low success rate, but there’s a billion websites out there.  You do the math.

High risk websites

Other websites have to worry about someone trying to actively hack their website.  There’s usually three possible reasons for this:

  • Your website has information worth stealing — Maybe your site has an e-commerce component, or a database of hundreds of thousands of membership records (with full names and e-mail addresses).
  • Your website has a lot of visitors — This is really just a subset of the first point.  If someone could infect all those visitors with a virus they could make a lot of money.
  • Someone wants to shut your website down — Maybe your organization has a political bent that some people strongly disagree with.

So what does this mean for my Drupal 6 site?

If your site is in the low risk category, then nefarious individuals will be using the vulnerabilities fixed by the LTS vendors in their automated attacks.  As long as your site continues to be updated with these fixes you are probably fine.  

There is still some risk if:

  • your site runs a module that the LTS vendors do not support,
  • and a vulnerability is found in the Drupal 7 version of that module,
  • and that vulnerability exists identically on the Drupal 6 version.

That’s possibly enough “ifs” to keep the risk at an acceptable level.

Also be aware that this support won’t last forever.  As more sites get off of Drupal 6, the LTS Vendors will have fewer clients paying for those services, and the number of supported modules will diminish.  Eventually your Drupal 6 site could be the last one standing with no one looking out for it.  How long this support is “good enough” is impossible to say.

If your site is in the high risk category, then you need to take a more active role in preventing successful attacks.  You could:

  • Move the information worth stealing somewhere else.
  • Move your site off of Drupal 6 faster.
  • Become a client of a Drupal 6 LTS Vendor to ensure that all of your modules are supported (not just the ones that other LTS Vendor clients happen to be using).

If you need help figuring out what you need, just contact us.

Photo by Billie Grace Ward

Apr 01 2016
Apr 01

The April 2016 issue of php[architect] magazine is out! This issue we take a look at how Drupal is using tools and techniques from the PHP community.

This issue also includes articles on how to easily generate documentation, advice on learning new frameworks, what it means to be a leader in the PHP community, and how to use PHPStorm to improve your code.

Download a FREE article and get your issue today.

Oscar still remembers downloading an early version of the Apache HTTP server at the end of 1995, and promptly asking "Ok, what's this good for?" He started learning PHP in 2000 and hasn't stopped since. He's worked with Drupal, WordPress, Zend Framework, and bespoke PHP, to name a few. Follow him on Google+.
Mar 29 2016
Mar 29

Data validation is a very important part of any application. Drupal 7 has a great Form API that can handle complex validation of submitted data, which can then be turned into entities. However, form level validation is problematic. For example, it becomes difficult to handle entity (data) validation programmatically. We have to either reimplement validation logic or mimic form submissions in code. This makes any data interaction dependent on the form system and this is a bad idea.

Drupal 8 logo

With the introduction of subsystems such as the REST API, Drupal 8 needed something better to handle this problem. The Symfony Validation component was chosen and Drupal 8 builds on top of it to tailor for the realties of the Typed Data and plugin based Entity system. So now, form submissions validate entities just like REST calls do or any other programmatic interaction with the entities easily can.

In this article, and its followup, we will explore the Drupal 8 Entity Validation API, see how it works, and how it can be extended. To better understand this, we will also take a look at the Typed Data API which underpins the entity system in Drupal 8. There will be some code examples that already exist in core but we will also write a bit of our own code which can be found in this git repository within the demo module.

Typed Data

Typed Data is the Drupal 8 API that was built to provide a consistent way of interacting with data or metadata about the data itself. Why is this important for our topic? Because validation is defined and invoked on typed data objects.

Two important components of this API stand out: the data definition and the DataType plugins. The role of the former is to define data and how interaction works with it (including things like settings or validation constraints). The role of the latter is to provide a way to get and set values from that type of data. When they are instantiated, data type plugins make use of data definition instances passed on by the plugin manager. The latter can also infer which data definition needs to be used by a DataType plugin type.

Let’s see an example:

$definition = DataDefinition::create('string')
    ->addConstraint('Length', array('max' => 20));

We created a string data definition and applied the Length constraint to it. Constraints are a key part of the validation API and they define the type of validation that will run on the data. They are coupled with a validator that actually performs the task, but we will see more about constraints and validators in the second part of this series.

Next, we use the DataType plugin manager to create the actual data type plugin instance:

$string_typed_data = \Drupal::typedDataManager()->create($definition, 'my string');

We loaded the manager service statically here for brevity but you should use dependency injection in your project if you are in a class context. The create() method on the TypedDataManager takes the data definition as the first parameter, the actual value as its second and returns a DataType plugin instance of the type that matches the definition: in our case StringData. For complex data, DataType plugins can specify in their annotations which data definition class they need to use. And for more information about plugins in Drupal 8, make sure you check out my previous articles on the topic.

One of the methods on this plugin instance is validate(), which triggers data validation against all the constraints that have been applied to the definition and returns an instance of Symfony’s ConstraintViolationList. By iterating over it or using methods like count() or get() we can check if the data is valid and which constraints have failed if not.

In our example, the violation list should have no validation errors because the string we used is under 20 characters. Had we used a longer string when creating the plugin, we would have had one violation represented by a Symfony ConstraintViolationInterface instance with a message, offending value and even a property path.

Typed Data and Content Entities

Now that we know a bit about the Typed Data API, let’s see how this applies to content entities.

Entity data in Drupal 7 is split between entity properties (usually the columns on the entity table) and Field API fields that are configured through the UI. In Drupal 8, they have been brought under the same umbrella so the old properties become fields as well. However, a difference still remains in that some fields (mainly the old entity properties) are defined as base fields while the rest are configurable fields.

The data definitions for these fields are BaseFieldDefinition and FieldConfig, but they are both implementors of the same FieldDefinitionInterface (which is a complex extender of the DataDefinitionInterface – the interface directly implemented by DataDefinition we saw earlier).

Each individual field holds data in a special FieldItemListInterface implementation and is always a list of individual FieldItem plugins (even if there is only one real value in the field). Each of these plugins extends a DataType plugin and uses a type of DataDefinitionInterface implementation itself (usually FieldItemDataDefinition). Things are quite complex at this level so it’s well worth taking a closer look at the makeup of entity fields to better understand this architecture.

Adding Entity and Field Constraints

Constraints in Drupal 8 are also plugins which usually hold a small amount of information about how data is actually being validated, what error message should be used in case of failure and any additional options the validator needs. The validator class (which is referenced by the constraint) is responsible for checking the data. We’ve seen one example, Length, which is in fact the LengthConstraint class validated directly by Symfony’s LengthValidator class. We will see in the second part how to create our own constraint and validator. For now, though, let’s see how we can add existing constraints to content entities and fields.

Entity level constraints

Entity level constraints are added in the annotation of the entity class itself. For example, this is how the Comment entity has defined a constraint for its name/author fields combination:

...
  constraints = {
    "CommentName" = {}
  }
...

In this example, CommentName is the plugin ID of the constraint that will be validated against when saving a comment entity. The opening and closing braces means that the plugin takes no options.

If we wanted to add to or remove a constraint from an existing entity, we’d have to implement hook_entity_type_alter():

function demo_entity_type_alter(array &$entity_types) {
  
  $node = $entity_types['node'];
  $node->addConstraint('ConstraintPluginName', ['array', 'of', 'options']);
}

In this example, we are adding a fictitious constraint to the Node entity and passing an array of options to it.

Field level constraints

There is more than one way to add field level constraints depending on whether the content entity type is defined in our module and whether the type of field we are talking about is a base field or configurable.

If we are defining our own entity type, one of the methods on the actual entity class that we have to implement is baseFieldDefinitions(). This is where we return an array of BaseFieldDefinition field definitions and we can easily add our constraints there. For example, this is how the Node ID base field is being defined:

$fields['nid'] = BaseFieldDefinition::create('integer')
  ->setLabel(t('Node ID'))
  ->setDescription(t('The node ID.'))
  ->setReadOnly(TRUE)
  ->setSetting('unsigned', TRUE);

Similarly to how we added constraints to the DataDefinition instance earlier, the Node entity could also add constraints to the Node ID field, more specifically:

  • to the BaseFieldDefiniton itself, which is, as we saw, the definition for the FieldItemListInterface implementation (the list)
  • to the individual FieldItemDataDefinition items, which are, as we saw, a type of complex data definition for the FieldItemInterface implementations (the items)

If we want to add a constraint to a Node base field (or of any other content entity type not defined by our module), we have to implement hook_entity_base_field_info_alter() and add our constraint there:

function demo_entity_base_field_info_alter(&$fields, \Drupal\Core\Entity\EntityTypeInterface $entity_type) {
  if ($entity_type->id() === 'node') {
    
    $title = $fields['title'];
    $title->addPropertyConstraints('value', ['Length' => ['max' => 5]]);
  }
}

In the example above, we are adding a constraint to the Node title field to make sure that no title can be longer than 5 characters. To notice is that we are using the addPropertyConstraint() method instead of the addConstraint() one we saw earlier. This is because we are not targeting the definition for the list of items but the individual item definitions themselves (FieldItemDataDefinition).

By using the addConstraint() method, we are adding a constraint to the entire list of items. This means that when the constraint gets validated, the validator receives the entire list not just the value of the individual item.

If we want to add a constraint to a configurable field, the process is quite similar. The difference is that we need to implement hook_entity_bundle_field_info_alter() and work with FieldConfig instances instead of BaseFieldDefinition.

If we want to inspect the constraints that are already set on the field, we can do something like this:

$title = $fields['title'];
$constraints = $title->getConstraints();
$property_constraints = $title->getItemDefinition()->getConstraints();

In this example, $title is either an instance of BaseFieldDefinition or FieldConfig. The $constraints array is, as expected, a list of constraints applied to the entire list of field items while the $property_constraints is an array of constraints applied to the individual field items themselves. We can notice, though, that if we run this code after we’ve applied the Length constraint, we will find inside $property_constraints a ComplexData constraint which wraps over the individual constraints applied to the field values. This is because there can be multiple individual data definitions for a single field item and Drupal by default groups them like so.

Conclusion

In this article, we’ve started looking at the Entity Validation API in Drupal 8. To this end, we also had to get a sense of the Typed Data API which is used as a foundation for the entity system. Once that became a bit clearer, we’ve seen how constraints can be added to various types of data definitions, including those used by entities and fields.

In the next part, we will look at how the actual validation works and how handling the violations that may occur should be done. Additionally, we will create our own constraint and validator and apply our knowledge from this part to various data definition types. Fun!

Daniel Sipos

Meet the author

Daniel Sipos is a Drupal developer who lives in Brussels, Belgium. He works professionally with Drupal but likes to use other PHP frameworks and technologies as well. He runs webomelette.com, a Drupal blog where he writes articles and tutorials about Drupal development, theming and site building.
Oct 24 2015
DA
Oct 24

Configuring Drupal with a remote database is possible and in some cases recommended.

Our EK management tools application is a particularly good case where this setup is very helpful. EK manages Drupal system configuration database and content database separately. In other words, the installed database from Drupal 8 and the database where all EK custom modules save their data are different.

This configuration brings few benefits:

  • security: is system data are compromised (i.e. user login information) the content data which is of high value for the organization have less chances to be affected. This also reinforced as the 2 databases are physically and geographically separated;
  • backup management; you can have a better backup management cycle with separated databases;
  • updates management; when updating Drupal, having a configuration database distinct from where the content is store will make it more efficient and faster;
  • as a vendor, you can keep control on the service by reserving control on the system configuration without having any interference on the customer content and information;

 The diagram below shows how we can implement an EK installation with remote database:

remote Drupal database setup

One important point is to keep the connection between the main server (this server can be the customer server for instance) and the configuration server secured with encrypted communication (ssl).

A good solution (we are experimenting now) comes with Amazon RDS service. The service can supply on demand access to mysql databases or any other database engine) and provide the necessary encryption keys.

Oct 07 2015
Oct 07

This morning, during my usual scan of Feedly/Twitter/Reddit I read Secure the data of visitors on your Drupal website better. The post shows you how to use the Field encryption module.

The Field encryption module ensures that the values stored in the Drupal database are encrypted. When the database ends up in the wrong hands, then nobody can read the data since this module has encrypted it. This way, you are prepared for a worse case scenario.

It all seems straight forward enough, but I suspected it wouldn’t be so simple and in fact doesn’t look as secure as purported. My main concern was with the 3 options presented for storing the private key used to encrypt data. So I asked on Twitter:

How secure is this if Drupal needs to read the key? http://t.co/q8wzlLy2dM /cc @enygma @Awnage @ircmaxell

— Oscar Merida (@omerida) October 7, 2015

Now, this post isn’t meant to denigrate the work of that project or to completely discount the advice on openlucius.com. Let’s see why some of the ways to store the key are problematic.

@enygma @omerida @Awnage the key is stored in the db? o_O

— Anthony Ferrara (@ircmaxell) October 7, 2015

The first option is to store the key in the database, and at least the article recommends against selecting that. If your key is in the database, and a malicious attacker manages to steal your database or find some way to read it’s contents via SQL Injection, they will have your key. With the key, nothing will stop them from unencrypting your data.

The second option is to specify it as a variable in settings.php. The key is a little harder to get but is only a variable_get('encrypt_drupal_variable_key') call away. Since settings.php is in the public web root, misconfiguring PHP or having PHP files show the source code will leak your key too. Finally, if you’re committing your settings files to git or SVN (hint: you shouldn’t be), anyone with access to your repository will also have your key.

@omerida imho they should only offer the last option. @ircmaxell @Awnage

— Chris Cornutt (@enygma) October 7, 2015

The final option, to use a File should be the recommended way to specify the key. Ideally, the file is somewhere outside of your web root and, again, not in your code repository.

Only in option 1 is your key vulnerable to SQL injection attack. For the other 2 options, an attacker would have to gain access to your code to get your key. Given how Drupal 7 stores routes in the database, all that takes is and SQLi vulnerability in another module or core itself and someone could install a back door or shell on your site.

@omerida @enygma @Awnage depends on a lot of factors. If done correctly (haven't looked yet), could make SQLi virtually useless by itself.

— Anthony Ferrara (@ircmaxell) October 7, 2015

No matter how you store it, if you have the PHP module enabled, anyone who can build a view or execute PHP code from the Drupal UI can retrieve your key. There’s also a temptation to share the key across development, testing, and production environments so that your database snapshots are portable between them all.

Others brought up issues on as well. The original module author added a comment highlighting that the Field Encryption module is still marked as Beta, which was released in 2013.Also, there are better key management solutions for Drupal.

@enygma @ircmaxell @omerida @Awnage the default options are bad, bad, and bad. Modules like townsec_key & key attempt to provide real KMS

— Cash Williams (@cashwilliams) October 7, 2015

Also, there are better algorithms for encryption than those in the module.

@ircmaxell @enygma @omerida @Awnage It's worse than that, the suggested plugin Encrypt, uses ECB & mcrypt with no authentication. *shrug*

— Ashley Pinner (@NeoThermic) October 7, 2015

Security is a Continual Process

This illustrates that security is a continual process, with a lot of considerations to take into account. It’s not as easy as installing a single module or ticking a box on a check list. If you’re storing really sensitive user data, ask yourself if you really need it. If this data is credit card information—get to know what it takes to be PCI compliant. Then ask if you aren’t better off using a payment processor instead. But please, don’t be lulled into a false sense of security after adding a single component.

Jul 15 2015
Jul 15

Regardless of industry, staff size, and budget, many of today’s organizations have one thing in common: they’re demanding the best content management systems (CMS) to build their websites on. With requirement lists that can range from 10 to 100 features, an already short list of “best CMS options” shrinks even further once “user-friendly”, “rapidly-deployable”, and “cost-effective” are added to the list.

There is one CMS, though, that not only meets the core criteria of ease-of-use, reasonable pricing, and flexibility, but a long list of other valuable features, too: Drupal.

With Drupal, both developers and non-developer admins can deploy a long list of robust functionalities right out-of-the-box. This powerful, open source CMS allows for easy content creation and editing, as well as seamless integration with numerous 3rd party platforms (including social media and e-commerce). Drupal is highly scalable, cloud-friendly, and highly intuitive. Did we mention it’s effectively-priced, too?

In our “Why Drupal?” 3-part series, we’ll highlight some features (many which you know you need, and others which you may not have even considered) that make Drupal a clear front-runner in the CMS market.

For a personalized synopsis of how your organization’s site can be built on or migrated to Drupal with amazing results, grab a free ticket to Drupal GovCon 2015 where you can speak with one of our site migration experts for free, or contact us through our website.

_______________________________

SEO + Social Networking:

Unlike other content software, Drupal does not get in the way of SEO or social networking. By using a properly built theme–as well as add-on modules–a highly optimized site can be created. There are even modules that will provide an SEO checklist and monitor the site’s SEO performance. The Metatags module ensures continued support for the latest metatags used by various social networking sites when content is shared from Drupal.

SEO Search Engine Optimization, Ranking algorithm

E-Commerce:

Drupal Commerce is an excellent e-commerce platform that uses Drupal’s native information architecture features. One can easily add desired fields to products and orders without having to write any code. There are numerous add-on modules for reports, order workflows, shipping calculators, payment processors, and other commerce-based tools.

E-Commerce-SEO-–-How-to-Do-It-Right

Search:

Drupal’s native search functionality is strong. There is also a Search API module that allows site managers to build custom search widgets with layered search capabilities. Additionally, there are modules that enable integration of third-party search engines, such as Google Search Appliance and Apache Solr.

Third-Party Integration:

Drupal not only allows for the integration of search engines, but a long list of other tools, too. The Feeds module allows Drupal to consume structured data (for example, .xml and .json) from various sources. The consumed content can be manipulated and presented just like content that is created natively in Drupal. Content can also be exposed through a RESTful API using the Services module. The format and structure of the exposed content is also highly configurable, and requires no programming.

Taxonomy + Tagging:

Taxonomy and tagging are core Drupal features. The ability to create categories (dubbed “vocabularies” by Drupal) and then create unlimited terms within that vocabulary is connected to the platform’s robust information architecture. To make taxonomy even easier, Drupal even provides a drag-n-drop interface to organize the terms into a hierarchy, if needed. Content managers are able to use vocabularies for various functions, eliminating the need to replicate efforts. For example, a vocabulary could be used for both content tagging and making complex drop-down lists and user groups, or even building a menu structure.

YS43P

Workflows:

There are a few contributor modules that provide workflow functionality in Drupal. They all provide common functionality along with unique features for various use cases. The most popular options are Maestro and Workbench.

Security:

Drupal has a dedicated security team that is very quick to react to vulnerabilities that are found in Drupal core as well as contributed modules. If a security issue is found within a contrib module, the security team will notify the module maintainer and give them a deadline to fix it. If the module does not get fixed by the deadline, the security team will issue an advisory recommending that the module be disabled, and will also classify the module as unsupported.

Cloud, Scalability, and Performance:

Drupal’s architecture makes it incredibly “cloud friendly”. It is easy to create a Drupal site that can be setup to auto-scale (i.e., add more servers during peak traffic times and shut them down when not needed). Some modules integrate with cloud storage such as S3. Further, Drupal is built for caching. By default, Drupal caches content in the database for quick delivery; support for other caching mechanisms (such as Memcache) can be added to make the caching lightning fast.

cloud-computing

Multi-Site Deployments:

Drupal is architected to allow for multiple sites to share a single codebase. This feature is built-in and, unlike WordPress, it does not require any cumbersome add-ons. This can be a tremendous benefit for customers who want to have multiple sites that share similar functionality. There are few–if any–limitations to a multi-site configuration. Each site can have its own modules and themes that are completely separate from the customer’s other sites.

Want to know other amazing functionalities that Drupal has to offer? Stay tuned for the final installment of our 3-part “Why Drupal?” series!

Jul 01 2015
Jul 01

Earlier this year, we launched a new site for the ACLU. The project required a migration from Drupal 6, building a library of interchangeable page components, complex responsive theming, and serious attention to accessibility, security and privacy. In this post, I’ll highlight some of the security and privacy-related features we implemented.

Privacy

As an organization, the ACLU has a strong commitment to protecting individual privacy, and we needed to translate their passion to this issue to their own website. This meant meeting their high standards at a technical level.

The ACLU ensures that technical innovation doesn’t compromise individual privacy, and most of our work around user privacy involved ensuring that third-party services like Facebook and YouTube weren’t accessing user data without their consent.

Social sharing

Facebook “Like” buttons on the site offer a quick way for visitors to follow ACLU content on their Facebook feed. But even if you don’t click to “Like” a page, the tracking scripts behind them – coming straight from Facebook – log your behavior and make note of your visit there. That data can be used for targeted advertising, and the data itself is also a sellable product. Because these buttons are all over the web, Facebook can piece together quite a bit of your browsing history, without your knowledge.

To prevent this from happening to ACLU site visitors, we hooked up a jQuery plugin called Social Share Privacy to make sure that visitors who want to “Like” ACLU can do so while others can avoid Facebook’s data tracking. The plugin initially loads a disabled (greyed-out) button for the Facebook “Like”. If the visitor wants to use the button, they click once to enable it, which then loads Facebook’s iframe, and then a second time to “Like” the page.

ACLU.org Facebook button

The Social Share Privacy jQuery plugin keeps Facebook from tracking you without your consent.

A nice side effect is a faster page load for everyone since we don’t have to load content from Facebook on the initial page render.

Video playback

YouTube and other video sharing sites present a similar privacy problem – the scripts used to embed videos can also dig into visitor data without their consent.

MyTube video embed

A MyTube video embed on ACLU.org.

MyTube is a script that was written by the Electronic Frontier Foundation as a Drupal 5 module, then updated as a Drupal 6 module by students in the Ohio State University Open Source Club. For the ACLU site, we worked on porting the module to Drupal 7 and updating various parts of the code to work with updated APIs (both on the Drupal end and the video host end).

Similar to the Social Share Privacy plugin, MyTube initially loads a static thumbnail image from the embedded video, and to play the video, the visitor gives it an extra click, opting-in to run code from the third-party site.

If you’re interested in helping complete Drupal 7 version of the module, take a look at some of the patches our team submitted, and test them out!

Security

Due to the ACLU’s high profile and involvement with controversial topics, security was a major concern throughout the development process. While we can’t go into too much detail here (because, well, security), here are a few steps we took to keep the site safe.

  1. Scrubbed database back-ups. When developers copy down database instances for local development, sensitive information – such as user emails and passwords – are removed. This is made pretty easy using Drush sql-sync-pipe.
  2. Secure hosting on Pantheon with controlled development environments. In addition, though our development team can make code changes, only a handful of authorized ACLU web managers can actually deploy change to their live site. 
  3. The site runs entirely over SSL via HSTS headers
  4. The previous version of the site had various “action” tools where visitors could log in to sign petitions and send letters to their elected representatives. During the redesign this functionality was moved to a separate site, on a separate codebase, running on separate infrastructure. Any site that allows anonymous visitors to create accounts is, by definition, more susceptible to attack. By splitting into two sites, a successful exploit of one web property will not affect the other.
  5. All custom code was reviewed by multiple members of the Advomatic team, and Tag1 Consulting performed an additional security review, in which our codebase received excellent marks and a glowing recommendation.

When your organization champions a cause, all your activities should embody it, including your website. The ACLU takes these standards very seriously, and so do we. Take a look at some of our other projects to see how we worked with nonprofits on sites that reflect their values. 

You should also check out

Jun 10 2015
Jun 10

One of the things that makes Drupal great is its flexible user permission system. The out of the box permissions grid we are all familiar with covers most uses cases of controlling what users can and cannot do. It is also very easy for module developers to create new permissions and roles that restrict the logic they implement.

Drupal logo

Nevertheless, I have encountered a practical use case where the default configuration options are not enough. Namely, if you need to have multiple users with access to edit a particular node of a given type but without them necessarily having access to edit others of the same type. In other words, the next great article should be editable by Laura and Glenn but not by their colleagues. However, out of the box, users of a particular role can be masters either of their own content or of all content of a certain type. So this is not immediately possible.

In this article I am going to show you my solution to this problem in the form of a simple custom module called editor_list. Article nodes will have a field where you can select users and only these users (or those who have full access) will be able to edit that particular node. You can find the module already in this git repository and you can install it on your site for a quick start. Do keep in mind that it has a dependency on the Entity Reference module as we will see in a minute.

I will keep the code comments to a minimum to save space but you can find them in the repository if you want. Basic knowledge of Drupal 7 is assumed in the remainder of this tutorial.

Scaffolding

We first need the editor_list.info file for our module to get us going:

name = Editor List
description = Module illustrating a custom solution for having multiple editors on a node.
core = 7.x
dependencies[] = entityreference

Next, we need our editor_list.module file where most of our business logic will be located. So go ahead and create it and we will populate it as we go on.

Finally, though not covered here, we can have an editor_list.install file where we can implement hook_install() and hook_update hooks to create fields and/or deploy configuration. In the repository, you’ll find that I provided an install hook that already creates an entity reference field called field_editors and attaches it to the Article content type. If you are following along but not using the code in the repository, you should go ahead and create the field manually through the UI. It’s a simple field that references User entities and allows for unlimited selections. Nothing major.

Node access

Going back to our .module file, it’s time to implement our access logic. First though, to make things as flexible and reusable as possible, let’s have a simple function that returns an array of node types to which we apply our access logic:

function editor_list_node_types() {
  return array('article');
}

Since we are only targeting articles, this will suffice. But we will use this function in multiple places so in case we need to target other types as well, we just have to update this array.

Next, let’s write another helpful function that returns all the user IDs set in the editors field of a given node. We will also use this in multiple places:

function editor_list_uids_from_list($node) {
  $users = field_get_items('node', $node, 'field_editors');

  $allowed_uids = array();
  if ($users) {
    $allowed_uids = array_map(function($user) {
      return $user['target_id'];
    }, $users);
  }

  return $allowed_uids;
}

I believe the function is quite self explanatory so I won’t go into details here. Instead, we can turn to our hook_node_access() implementation that gets called by Drupal whenever a user tries to do something with a node (view, edit or delete):

/**
 * Implements hook_node_access().
 */
function editor_list_node_access($node, $op, $account) {
  $node_types = editor_list_node_types();

  if ( ! is_object($node) || ! in_array($node->type, $node_types) || $op !== 'update') {
    return NODE_ACCESS_IGNORE;
  }

  $allowed_uids = editor_list_uids_from_list($node);

  if (empty($allowed_uids)) {
    return NODE_ACCESS_IGNORE;
  }

  if (in_array($account->uid, $allowed_uids)) {
    return NODE_ACCESS_ALLOW;
  }
}

So what’s happening here?

First, we use our previously declared helper function to get the list of node types we want to target, and we basically ignore the situation and return if the node type of the currently accessed node is not within our list or if the operation the user is attempting is not of the type “update”. Then we use our other helper function to check if there are any users in the editor list for this node and again ignore the situation if there aren’t. However, if there are, and our accessing user is among them, we return the NODE_ACCESS_ALLOW constant which basically gives the user access to perform the attempted operation. And that’s it.

You can check out the documentation for more information about how this hook works.

Let’s say you have admin users who can create and edit any type of content and regular authenticated users who cannot edit articles (apart from maybe the ones they created themselves). Adding one of these latter users to a node’s editor list would give them access to that particular node. And another great thing is that since this is all nicely integrated, contextual filters and tabs also take these dynamic permissions into account.

Field access

We now have a working module that does what I initially set out for it to do. But let’s say that your admin users are the only ones responsible for adding users to the editor lists. In other words, you are afraid that if your editors can edit their nodes and remove themselves from the list, they’ll get locked out of the node they are supposed to work on.

To account for this situation, we need to implement a field access check and remove the possibility that editors tamper with that field. Implementing hook_field_access should do the trick nicely. And if you are wondering, this hook is similar to hook_node_access() but is responsible for individual fields rather than the entire node (+ a couple of other small differences).

/**
 * Implements hook_field_access().
 */
function editor_list_field_access($op, $field, $entity_type, $entity, $account) {
  $node_types = editor_list_node_types();
  if ($entity_type === 'node' && is_object($entity) && in_array($entity->type, $node_types)) {
    return editor_list_control_field_access($op, $field, $entity_type, $entity, $account);
  }
}

And here we have it. There are a few more parameters because this hook gets called for all entities, not just nodes. But again, we check if the currently accessed node is one of those we defined earlier (and that the entity is in fact a node) and this time delegate to another function to keep things tidier:

function editor_list_control_field_access($op, $field, $entity_type, $entity, $account) {
  if ($op !== 'edit') {
    return;
  }

  $uids = editor_list_uids_from_list($entity);
  if (!in_array($account->uid, $uids)) {
    return;
  }

  $deny = array('field_editors');
  if (in_array($field['field_name'], $deny)) {
    return false;
  }
}}

Since we only care if the user is trying to update a particular field, we return nothing if this is not the case. Keep in mind that the op string here is edit and not update as it was in the other hook. This is just one of those Drupal quirks of inconsistency we all came to love so much. And like before, we ignore the situation if the current user is not part of the editor list.

Then, we define an array of field names we want to deny access to (in our case only one but we can add to it depending on the use case). Finally, we return false if the currently accessed field is part of our $deny array. Yet another difference here in that we have to return a boolean instead of a constant like we did before.

Now the editors in the list of a given node cannot remove themselves or add anybody else to the list. But then again, in some cases you may want this functionality and in others not. It’s up to you.

Tidying up

The last thing I am going to show you here relates to organization and maybe a bit of user experience. With our current implementation, the editor list field on the Article nodes is present somewhere on the form (wherever you dragged-and-dropped it when editing the field settings). However, wouldn’t it be nice if it were automatically part of the Authoring information group at the bottom of the page? Something like this:

Drupal 7 multiple editors per node

I think so. Let’s see how we can do that.

First, we need to implement hook_form_alter or one of its variations. I prefer the most targeted one to avoid unnecessary calls to it and a bunch of conditional checks:

/**
 * Implements hook_form_BASE_FORM_ID_alter().
 */
function editor_list_form_article_node_form_alter(&$form, &$form_state, $form_id) {
  $form['#after_build'][] = 'editor_list_node_form_after_build';
}

We went with the BASE_FORM_ID of the article nodes here so if we extend our application to other types we would do the same for those as well. Inside, we just define an #after_build function to be triggered when the form has finished building. This is to ensure all the form alterations have been already done by contributed modules. All that is left to be done is to write the function responsible for making changes to the form:

function editor_list_node_form_after_build($form, &$form_state) {
  $field = field_info_field('field_editors');
  if ( ! field_access('edit', $field, 'node', $form['#entity'])) {
    return $form;
  }

  if ($form['author']['#access'] === 0) {
    return $form;
  }

  $field_editors = $form['field_editors'];
  $field_editors['#weight'] = 0;
  $form['author']['additional_authors'] = $field_editors;
  $form['field_editors'] = array();

  return $form;
}

This looks complicated but it really isn’t. We begin by loading the field definition of our editor list field. This is so that we can run the field_access check on it and just return the form array unchanged if the current user doesn’t have access to the field. Next, we do the same if the current user does not have access to the author group on the form (this is the Authoring information group we want to place the field into). And lastly, we make a copy of the field definition, change its weight and place it into the group, followed by unsetting the original definition to avoid having duplicates.

And that is pretty much it. Now the editors list field should be tucked in with the rest of the information related to authorship.

Conclusion

In this article, we created a solution to a content editing problem that Drupal 7 could not fix out of the box. However, it did provide us with the development tools necessary to make this an easy task inside of a custom module.

We now have an editor list field on the article node form by which we can specify exactly which users have access to that particular node. Though do keep in mind that in order for this to be of any use, the users you add to these lists must not have a role that allows them to edit all article nodes. Otherwise you won’t see much of a difference.

Mar 16 2015
Mar 16

Security is an important aspect to keep an eye for, and this time it’s about preventing clickjacking on Drupal and other Apache web applications.

Edit apache’s configuration file, which may be your declared vhost or such, usually at a location like /etc/httpd/conf.d/default.conf and make sure the  following

<IfModule mod_headers.c>
Header always append X-Frame-Options SAMEORIGIN
</IfModule>

This will disable embedding your website as an iFrame.

0013_clickjacking

Mar 09 2015
Mar 09

Apache Obfuscation can be achieved very easily and the benefits are great – it doesn’t disclose server information such as versions, OS, and does output verbose errors when ‘bad things happen’, and they happen.

2870445260_82be0db1db_z

Edit apache configuration, usually available here for RedHat based distributions: /etc/httpd/conf/httpd.conf

Make sure the following settings are present, save, and restart apache:

TraceEnable Off
ServerSignature Off
ServerTokens Prod

How do we test that this is actually working?

How to TraceEnable:
1. curl -v -X TRACE http://…
2. Confirm you get a forbidden response

How test ServerTokens:
1. Make a request to the website and check the response headers
2. Confirm the response contains only “Apache” information in the Server header

How to test ServerSignature:
1. Make a request to the website for a URL that should respond with Apache server error
2. Confirm you don’t see information about the apache server software version, OS, etc.

Mar 07 2015
Mar 07

Previously we read how to be a webmaster at drupal.org , Now I became the git administer at drupal.org. So I think to write a blog post so that others can benefit and also get to know how to become git administer.

In simple words: "Start Contributing". Git Administer privileges are granted to the users with proven record of contributions in the Project Applications issue queue. A solid history of consistent contributions on drupal.org is a must to get consideration for an elevated role.

How to start contributing & where you can contribute :

  1. Join the code review group
  2. Read How to review full project applications
  3. Some helpful tools for reviewing :
  4. Learning Sources : 
  5. if you found any problem while contributing,just comment on the below post/ if you need immediate answer you can try and find one of the git administer on IRC - #drupal-codereview IRC channel on Freenode.

Benifits of becoming git administer :

  1. You will see a new challenging case in every new project application.
  2. Your drupal apis knowledge will become sharp.
  3. Many more....

I would encourage you to learn more about that process and join the group of reviewers.
Next article:  A guide to review project applications
Feb 23 2015
Feb 23

Security of the Drupal website is a important stuff for the site owners, site developers.This blog post has my presentation at the Drupal Camp Mumbai that  intended for Drupalers who want to avoid security loop holes while writing code or architecting solutions. We delved into common security issues that ails custom code and has both vulnerable and secure code snippets.This is mostly about my encounters and experience after doing 50+ project application reviews and also a good guideline for new contributors.

[embedded content]

Hack Proof Your Drupal Site from Naveen Valecha

Next article:  A guide to review Project Applications.


Jan 23 2015
Jan 23

Was looking out some good English Speaking training course website for my cousinto become a fluent English speaker.


On opening the homepage I found the section "Free trial".

I did the same thing as all guys do.Click on the Free trial link,created my account.I personally feeling happy to get the 5 free audio English lessons.
I clicked on one of my lessons link and come to the page, found the download link of the audio file.



Copied and pasted the url in the browser and the downloaded the file. https://www.dailystep.com/en/download/file/fid/13531 Just change the fid in the url and tried to download some random file with file id. I thought what the Shit!   I then look around which drupal module has provided this route.After checking I got to know that this is the download file module which provides this route.After checking I assume that it might be permission stuff problem.
I found the similar permission problem on the drupal.org as well https://www.drupal.org/node/2394993
Trust is the Major Strategy in Security of any web application.We should be sure which user role we should assign which permissions.
Note: Published the post after suggesting the fix to the site owner Jane
Oct 31 2014
Oct 31

The recent announcement of Drupal SA-CORE-2014-005 caused a global scramble amongst Drupal site owners, developers and hosting providers to patch their sites and protect themselves from the vulnerability. Unfortunate site owners who weren’t quick enough were left with a site audit to ensure all traces of any successful attacks were removed from their environments.

Firstly, hats off to the Drupal Security Team, Core release co-ordinators and the Drupal community in general for a rapid, considered and clear response to the issue. The early warning that a security release was coming was well stated enough to make it clear to many that it would be a major issue. The normal release time was brought forward to a more suitable timeslot to ensure the maximum audience saw it early, and the post-release guidance, FAQs and blog posts covered all aspects from how to patch, what to do if your site had been hacked, and what to look out for to indicate if you had been affected. A follow up public service announcement PSA-2014-003 was published drawing further attention to the risks to unpatched sites and offering further guidance.

Secondly, excellent work from Sektion Eins, the penetration testing experts who detected the vulnerability. This was a defect that has existed for many years, and many organisations will have run penetration tests that haven’t previously detected it. Having been creative enough to find the vulnerability, it was then reported and managed responsibly, which should be praised.

Now, I don’t want to focus on SA-CORE-2014-005 any further, but instead I want to talk about some ways we can protect our Drupal sites and minimise our exposure to vulnerabilities. Whilst bugs will always happen (whether security or functional), there are steps we can all take to mitigate our exposure and respond quickly to incidents.

Early warning systems

The best cure is prevention, and the next best is to catch it early. There are lots of ways to keep up to date with what is going on in Drupal security:

  • The Drupal Security pages contain the most recent core, contrib and public service announcements for Drupal and include RSS feeds
  • Sign up for the Security Announcements mailing list (login to Drupal.org, go to your user profile page and subscribe to the “Security announcements” on the Edit » My newsletters tab)
  • Follow @drupalsecurity on Twitter

All three of these routes will ensure you’re on the quickest possible route to hearing about new security releases. It then becomes quick and easy to review the latest threats, decide if you’re vulnerable (by reviewing the mitigations - a lot of vulnerabilities depend on elevated roles or other mitigations, and these will be clearly described on each Security Advisory), and how quickly you ought to upgrade your core installation or other modules.

It’s also worth having the Update module enabled in your dev environment to phone home and check if there are updates for any of your modules available - however if like me you only login to some sites occasionally then you’ll want a backup strategy for keeping you informed.

It should then become almost ritual that for each alert you:

  • Determine if your core version is affected
  • Determine if you use the contributed module reported as affected
  • Reviewing any mitigations (vulnerability requiring elevated permissions etc) that may keep you safe from the vulnerability and reduce the urgency of patching/upgrading
  • For any urgent updates, apply as soon as practically possible
  • For any non-urgent updates, apply to normal dev/test/release cycle and deploy in your next release slot

Don’t leave the back door open

The great thing about Drupal is the wide range of contributed modules that you can use to kickstart your development and re-use functionality that other people have already built for you. However, this comes with its own risks - as you’re effectively installing code that you’ve not written and so have no guarantees of how secure it may be.

With this in mind, it’s essential to review the modules you download, rather than just installing them right-away. Just as we check if modules contain any potential performance gotchas, we also look to see if there are any obvious security flaws - use of $_GET or $_POST variables in templates, data directly concatenated into SQL queries, no roles or permissions defined, all gives clues, and we can use Drupal secure coding guidelines, and awareness of the OWASP Top 10, to inform our reviews.

To some degree, these checks can be automated by running things like Coder, which includes some basic security checks and has some good proposals to add more security sniffs. Modules like Security Review can also check for some easy-to-make mistakes which may render your site insecure - and are invaluable, particularly if you’re new to site security. However, automated checks are only as good as the information they’re fed with, so there is no substitute for getting in and reading the code - you were going to look to see how it worked anyway, right?

Remember - if you do spot any security flaws in Drupal Core or Contrib, don’t raise issues in the public issue queues, make sure you follow the process to report a security issue to the security team, so that it can be fixed in private and released before the vulnerability is made public.

Constant vigilance

It’s not just Drupal that can be exposed to vulnerabilities such as these, PHP itself has had its share over the years, and realistically no large body of code is going to go its entire life without some vulnerabilities creeping in. There are also many more people trying to find vulnerabilities to take advantage of than there are people trying to fix them.

This means keeping your entire platform secure becomes a constant activity, so a reliable and repeatable test and release cycle becomes essential - if pulling down the latest updates and deploying them takes a significant amount of time, the odds are that you’ll get lazy and skip an udpate or two. This soon becomes the security guys nightmare as sites, services and platforms become more out of date and more vulnerable to attack.

Watch the watchman

All the attention paid to Core and Contrib security updates is very valuable, but it becomes worthless if you don’t give the same care to the code you and your team write in custom modules. An awareness of how to follow Drupal best practices to write secure code is an essential part of the training and education of any good Drupal developer. Fortunately Drupal provides some excellent abstraction layers to remove some of the thinking on these topics, so make sure you use the database layer correctly, handle text securely, and create forms in a safe way, as well as all the other best practice.

It’s also well worth commissioning penetration tests from external specialists to test your implementation and validate that it is secure. We use the expertise of these companies regularly, and rotate through a list of preferred companies to ensure that we’re constantly getting fresh eyes on the solutions, and varied approaches to testing, so as to maximise the chances of finding issues. The tests often prove their worth, and whilst every developer hates having defects raised, we’d all much rather the security issue be in a test environment than in production!

Reading list

To finish, here are some excellent resources to keep up to date with best practice approaches to keeping your Drupal installation secure:

Oct 22 2014
Oct 22

I estimate hundreds of thousands of Drupal websites now have backdoors; between ten and ninety percent of all Drupal websites. Automated Drupageddon exploits were in the wild within hours of the announcement. Updating or patching Drupal does not fix backdoors that attackers installed before updating or patching Drupal. Backdoors give attackers admin access and allow arbitrary PHP execution.

If your Drupal 7 (and 8) website is not updated or patched it is most likely compromised. If your website was not updated within a day of the announcement, it is probably compromised. Even if your website was updated within a day, it may be compromised.

If you did not know, Drupageddon is the highly critical SQL injection vulnerability in Drupal core announced 15 October. It is also known as Drupalgeddon (with an "L"), CVE-2014-3704, Drupal SA core 2014 005 and #DrupalSA05. Drupageddon (no "L") is the original name selected by Stefan Horst, who initially reported to the Drupal security team. See Drupageddon.com.

I have drafted this flowchart to help Drupal website administrators understand their options for recovering from Drupageddon. Review, feedback and collaboration is welcome.

The flowchart is a living document. Currently version is number 7.

Updates

How to fix a Drupal site compromised by Drupageddon

Creative Commons License

Oct 16 2014
Oct 16

Are you done updating your nginx and apache servers to no longer support SSLv3 and prevent the POODLE attack? Well, now it’s time to upgrade your Drupal 7 sites to version 7.32, as a significant SQL injection vulnerability has been fixed in that update. Exploits are sure to follow, if they aren’t already in the wild.

SA-CORE-2014-0044

The technical writeup of the exploit is, in my opinion, actually very light in providing technical details. Helpfully, there’s a simple patch to prevent the attack. If you can’t do a full upgrade right now, go apply the patch. The exploit can be used by anonymous attackers, so an ounce of prevention here will pay off. Let’s take a look at the patch:

diff --git a/includes/database/database.inc b/includes/database/database.inc
index f78098b..01b6385 100644
--- a/includes/database/database.inc
+++ b/includes/database/database.inc
@@ -736,7 +736,7 @@ abstract class DatabaseConnection extends PDO {
// to expand it out into a comma-delimited set of placeholders.
foreach (array_filter($args, 'is_array') as $key => $data) {
$new_keys = array();
- foreach ($data as $i => $value) {
+ foreach (array_values($data) as $i => $value) {
// This assumes that there are no other placeholders that use the same
// name. For example, if the array placeholder is defined as :example
// and there is already an :example_2 placeholder, this will generate

The fix is to change the foreach loop to ensure it loops through a numerically indexed array of values. Without the call to array_values, malicious attackers could inject SQL conditions via the array’s keys, which are used to name the expanded placeholders. The post on sucuri.net about the exploit shows the manipulated SQL statement. A good discussion of the attack can also be found on the PHP subreddit.

But…PDO?

I was a bit stumped at first. Drupal 7 is using PDO and prepared statements, so it should be safe from SQL injection. Right? Diving into the affected file, this foreach loop is in a function, expandArguments that “supports an alternate syntax for doing arrays of values”. Looking at the example from the advisory:

The function assumes that it is called with an array
which has no keys. Example:

  db_query("SELECT * FROM {users} where name 
    IN (:name)", array(':name'=>array('user1','user2')));

Which results in this SQL Statement

  SELECT * from users where name IN (:name_0, :name_1)

with the parameters name_0 = user1 and name_1 = user2.

The Problem occurs, if the array has keys, which are 
no integers. Example:

  db_query("SELECT * FROM {users} where name IN (:name)", 
     array(':name'=>array(
       'test -- ' => 'user1',
       'test' => 'user2')
     )
  );

this results in an exploitable SQL query:

  SELECT * FROM users WHERE name = :name_test -- 
    , :name_test AND status = 1

with parameters :name_test = user2.

Since Drupal uses PDO, multi-queries are allowed. So this 
SQL Injection can be used to insert arbitrary data in the 
database, dump or modify existing data or drop the whole 
database.

So, because the array keys were not filtered nor sanitized, attackers can change the resulting SQL. Coupled with the fact that PDO allows multi-queries by default, a single call could execute an insert, update, delete, drop statement along with the original select statement.

Disabling Multipe Queries

Don’t use Drupal? Because PDO uses emulated prepared statements, If you’re using PDO to interact with MySQL, you may want to disable multiple queries in your PDO statements as a safeguard. Though you’ll also lose the ability to “use a named parameter marker of the same name more than once in a prepared statement”. Read the PHP documentation for PDO::prepare, first. To disable it:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

Security is Ongoing

This attack reinforces that security is hard and ongoing. You can’t trust user input, so remember to always Filter Input, Escape Output (FIEO). Kudos to the Drupal security team for addressing and publicizing the vulnerability. While it’s unfortunate that an exploit was found, it’s comforting to know that the project has a team dedicated to security.

Jun 26 2014
Jun 26

TimeBanks USATimeBanks USA is a 501c3 nonprofit organization that promotes and supports timebanking. Timebanking was created by Dr. Edgar S. Cahn, who founded TimeBanks USA in 1995.

Timebanking is a tax-exempt alternative currency system that works like this: if I spend one hour helping you build your website, I earn one credit, or time dollar. You can then turn around and exchange that time dollar by giving it to someone who fixes your refrigerator, coaches you on your resume, or gives you a ride to the airport.

The possibilities are endless,” according to TimeBanks USA. “An hour of gardening equals an hour of childcare equals an hour of dentistry equals an hour of home repair equals an hour of teaching someone to play chess.” It’s different from bartering, because this type of timebanking is based on services (and not goods) between members of a network.

This wasn’t the first time Exaltation of Larks has worked with alternative currencies. We created a virtual economy for Digital Dollhouse, a casual game where girls are empowered to become their own interior designers. In this virtual world, it’s possible to trade or regift items like dolls, plants and pets, and work with an in-game currency named ddCoins.

In addition to our work with TimeBanks USA, our experience with timebanking includes working as volunteers with two Los Angeles-area timebanks: Arroyo S.E.C.O. Time Bank and the West LA timebank cleverly named Our Time Bank. Our Time Machine project is an experimental Drupal installation profile for communities and organizations looking for turnkey timebanking software for their members and participating businesses and organizations.

TimeBanks USA founder Dr. Edgar S. Cahn has spent more than four decades striving for social justice. He began his career working for the Kennedy administration, focusing on alleviating poverty and hunger. He then opened the Citizens Advocate Center, an organization dedicated to protecting the rights of community groups as they interacted with the government. In 1972, Dr. Cahn founded the Antioch School of Law, whose curriculum was designed to teach students to practice law for the greater good of society.

Here at Exaltation of Larks, we have enormous respect for Dr. Cahn: at the age of 80, he is still a rabble-rouser and hell-raiser who is fighting to change the world, and we’re proud to provide him with the technical assistance to further this goal. Dr. Cahn is a true visionary and we hope to work with — and write about — him and his partner, Chris Gray, TimeBanks USA’s CEO, more in the future.

TIMEBANKS USA’s ROLE IN TIMEBANKING

TimeBanks USA TimeBanks USA supports timebanking in myriad ways, including offering onsite trainings nationwide; organizing an annual timebanking conference; hosting webinars and teleconference calls; and consulting individually with clients. The organization helps members connect with local timebanks or create their own.

One of the parts of TimeBanks USA infrastructure is a large scale social networking platform named Community Weaver, which has a software-as-a-service subscription model. There are more than 400 timebanking websites all around the world that rely on it to help manage and organize their timebanking processes, community activities and other needs.

TIMEBANKS USA’s NEEDS

Exaltation of Larks performed a substantial security and performance audit on Community Weaver, a complex Drupal multisite system. We helped TimeBanks USA fix critical issues affecting one of their essential online organizational tools — their Community Weaver software. This software platform runs a quickly evolving and iterating network of Drupal websites, so it was vital that the software could be updated and developed sustainably and seamlessly, yet without overriding the autonomous decision-making processes of each chapter website.

In addition, we worked with TimeBanks USA to develop a project plan for version 3.0 of Community Weaver and raise the funds to build it; we addressed problems arising from the system’s simultaneous use of both WordPress and Drupal; and we helped streamline the organization’s decision-making process.

TimeBanks USA needed extensive rework on their Community Weaver software, specifically with regard to security, performance and usability issues. Community Weaver is an online organizing and tracking tool for timebank members: it records time exchanged, displays service offers and requests, keeps track of memberships, and displays announcements for the community. Any local timebank can subscribe to TimeBanks USA’s software-as-a-service (SaaS) system to manage their members’ work. TimeBanks USA hired Exaltation of Larks to audit and rework Community Weaver 2.0, with the plans to eventually migrate all their technology, online memberships and e-commerce data to version 3.

TimeBanks USA was also experiencing security problems with its self-hosted WordPress website, which was outside our original scope of work. TimeBanks USA used our emergency support system and we quickly mobilized to resolve this new issue. We determined that security had been compromised and implemented several solutions to tighten it up, from checking the code integrity to updating MySQL access and hardening file permissions.

In addition to our work with TimeBanks USA, we worked with the Arroyo S.E.C.O. Time Bank, one of the many timebanks affiliated with TimeBanks USA. Arroyo S.E.C.O. serves neighborhoods in the eastern and northeastern Los Angeles area, which meant the Larks who were in the Downtown Los Angeles area could work with them one-on-one.

OUR SOLUTION

We began by tackling the security issues found in Community Weaver. Fortunately, TimeBanks USA had an in-house Drupal developer, who we worked with on a massive infrastructure audit, focusing on security and performance. This multisite installation had been built by its previous developer with development practices that were common in 2007, before Features and configuration-in-code became popular. We identified which multisite instances had been modified by their local chapters’ coordinators — which meant examining data structures, views, and content types across hundreds of Drupal websites — and which had unsafe code or configuration. We found security vulnerabilities through the entire stack, from the Drupal systems and websites down to the server operating system, all of which we documented, prioritized and / or resolved.

This was an extensive audit that had both technical and political ramifications. Each chapter is run by its coordinators and volunteers and sometimes in completely different ways than other chapters. In a multisite environment, making technical decisions for the entire fleet of hundreds of websites would impact all local chapter websites that had been modified for their own business cases.

We worked in conjunction with TimeBanks USA to devise policies and joined them on many global community conference calls — open to all coordinators of all the timebanks in the world — to describe our technical approach and to solicit feedback. Our task was to provide technical leadership for the entire organization. We needed a set of standards for sustainable development of this enormous network, but we also needed to respect each individual chapter’s right to make its own decisions.

The project plan we provided included time estimates to address the security problems we found. TimeBanks USA’s tech coordinators reviewed our list of most-needed fixes and then we consulted with a local timebank coordinator and Community Weaver user to make sure these fixes matched their timebank’s list of essential tasks.

We worked with several popular web hosting providers, including Drupal-as-a-service platform companies, to negotiate competitive pricing on behalf of TimeBanks USA. Due to their unique system and web application architecture, we recommended SoftLayer based on their features and pricing.

TimeBanks USA Community Weaver

The unfortunate multisite architecture that the prior developers had devised had the result of creating exponential complexity precluding any proper maintenance and further development on the system. We navigated our way through thousands of lines of uncommented custom code. We also found that the Linux server environment was an abandoned and unsupported custom distro. In both cases, we replaced as many unknown components as possible with stable, peer-reviewed alternatives and we documented the rest. We also stabilized the system by locking down the kinds of changes that individual coordinators could make to their individual timebank chapter websites, thus reducing future maintenance costs.

We fixed several security issues in the system by altering file permissions, MySQL accounts, and text input filters. We used PHP Filter Lock, a module we developed that disables the text form fields that contain PHP code, thereby mitigating the risk of CSRF and XSS security threats on websites that have the core PHP Filter module enabled.

On the same server as the Drupal multisite network was a WordPress marketing website. This in itself is not a problem. Exaltation of Larks’ position is that WordPress is great for simple websites and Drupal is great for complex systems and web applications. Having both on the same server created unnecessary security issues, however. The WordPress installation was technically able to overwrite anything on the Drupal side as well as access the Drupal database. We changed all MySQL usernames and passwords and locked down the file permissions so that the WordPress website could no longer be overwritten or be a risk to other software on the server, including Community Weaver.

Next, we worked with TimeBanks USA to develop the requirements for the next version of Community Weaver. The materials we developed included specifications for a fully featured mobile app, a business plan with financials and pitch deck, and more, and were designed to help TimeBanks USA secure additional funding. In the meantime, we trained a member of their community to maintain the software so they could further reduce their total cost of ownership.

Exaltation of Larks also provided TimeBanks USA with communications strategy consulting services. We performed a 360-degree organizational audit and came up with a more streamlined decision-making process. We created flowcharts of all the key players and stakeholders at TimeBanks USA and highlighted the points at which they had both strengths and weaknesses, and made recommendations where more efficiency was needed.

COMMUNITY INVOLVEMENT

Timebanking has evolved very differently in other parts of the world in ways that no one could have predicted. Nowhere is this emergent behavior more apparent than in highly populated cities, where the numbers, density, and different practices around timebanking create vastly different needs. One such advanced timebank is the Arroyo S.E.C.O. Time Bank in Los Angeles, which has thousands of members across dozens of separate neighborhoods. They needed several custom workflows implemented on their individual timebanking website to manage the scale that had resulted from their impressive growth. By its very nature, the timebank had no money for further development on their individual website.

Barnraisings are a concept taken from Amish culture, where the community comes together to build a barn for a newly married couple who wouldn’t be able to afford the time or expense of building a barn on their own. In the context of web development, barnraisings are like code sprints where the programming community gets together with a deserving nonprofit, and works with them to create or improve their software. For the development community, this is a teaching experience, and newer developers get to learn from seasoned veterans about client relationships, requirements gathering, project planning and the tools used for effective teamwork. The nonprofit brings food — usually excellent food — and everyone benefits.

Starting in April, 2012, the Larks partnered with Droplabs and arranged three separate barnraisings to build new features for the Arroyo S.E.C.O. Time Bank. Not only was a good time had by all, the team built functionality that the Larks turned into Features-based modules that could then be securely distributed to the other timebanks, to be turned on, or not, according to the wishes of each individual timebank coordinator. Features built included a custom registration workflow, neighborhood-specific blogs, and structured data types for content, among others.

PROJECT OUTCOME

Previous to Exaltation of Larks coming on board, TimeBanks USA had been working with a different development company. The Community Weaver software proved challenging to rework and over the 2 years we worked together we ensured that key security and performance problems with the software were resolved.

TimeBanks CEO Chris Gray says of the project: “Given the importance of the software for the mission and vision of TBUSA, and given how much we had to learn, this was a very intense experience for us.”

In addition, with the help of the volunteers at the barnraisings, we added several new features to the Community Weaver software, including a blog post content type and RSVP feature that integrates with the Signup module. These features directly benefit all the hundreds of TimeBanks chapters around the world that use the same Drupal distribution of Community Weaver.

All members of the Larks team, from the principals to the project leader to the programmers, demonstrated that they cared deeply about the quality of the work undertaken,” Chris Gray said. “[They] provided many hours of consultation to this endeavor. We are truly grateful for those contributions. Under challenging circumstances, they provided highly professional services to TBUSA. We greatly appreciate the professionalism of the Larks and the ongoing willingness to go above and beyond.”

Jun 02 2014
Jun 02

You’ve probably come across this situation before. When visiting a certain site, you see a browser warning that the website is using mixed content — both HTTP and HTTPS together.

Avoiding mixed content is nothing new to some web developers, but read on if you’re looking for a quick fix to prevent both mixed content warnings and CSRF attacks, which are the underlying reason why browsers have those warnings in the first place.

Introducing HSTS

HSTS, or HTTP Strict Transport Security, is a security implementation that was created in 2012. It’s been part of our standard security package for a while and we would love to see more websites using it.

read more

Jul 15 2013
Jul 15

Most experienced Drupal developers have worked on sites with security issues. Keeping modules up to date is a pretty straight forward process, especially if you pay attention to the security advisories. Coder can find security issues in your code.

Recently I needed to perform a mass security audit to ensure a collection of sites were properly configured. After searching and failing to find a module that would do what I needed, I decided to write my own. The Security Check module for Drupal checks basic configuration options to ensure a site configuration doesn't have any obvious security flaws. This module isn't designed to find all flaws in your site.

Security Check works by checking a list of installed modules, settings for variables and permission assignments. I hope that others in the community will have suggestions for other generic tests that can be implemented in the module. If you have any ideas (or patches), please submit them as issues in the queue.

This module isn't a substitute for a full security audit, which can be conducted in house or by a third party such as Acquia's Professional Service team. Security Check is designed to be run as part of an automated site audit to catch low hanging fruit.

To use Security Checker install it in ~/.drush and then cd to any docroot and run "drush security-check" or if you prefer to use an alias run "drush @example secchk" from anywhere.

Bookmark/Search this post with

Mar 30 2013
Mar 30

At the Boston Drupal meetup that was at Acquia this month, several presentations were focused on “what’s new in Drupal 8” from the view of several people who now work at Acquia. I loved it. There were other presentations, as well (including one of my own!), and I really enjoyed seeing the Boston Drupal group again after many months.

During the questions and answers part of the meetup, I asked Dries if he was considering naming a security maintainer for Drupal 6 when Drupal 8 is released. (In case you didn’t know, support for Drupal 6 will be discontinued by the Drupal core and security teams. See the handbook page on backwards compatibility at https://drupal.org/node/65922 for more, including Dries’ original statement on the subject in 2006.)

read more

Feb 04 2013
Feb 04

It's a question we all ask ourselves: What would I do if my site or server was compromised? Security professionals have loads of checklists to follow, and experienced server administrators drill for those moments. As we saw when Twitter.com was recently compromised by hackers, "Reset everyone's passwords, right away!" is almost always one of the important steps. If you run a Drupal site, that particular step can be frustrating. Resetting user passwords one by one is incredibly time consuming, and there's no way to do it for everyone in one fell swoop. At least, there wasn't until the release of the Mass Password Reset module…

Screenshot of administration screen

This recently-released module gives administrators a simple, straightforward admin page where they can reset every user's password with a single click. Notification emails can optionally be sent out to each user, just as if they'd requested the password reset themselves. (If you're using the module as part of the response to an actual security incident, it's probably a good idea to modify the standard password reset email before you click the "reset" button -- explaining why they've been reset is important, and unfortunately the module doesn't let you override it right from its bulk reset screen.) You can also choose to reset the root administrator's password (User 1 on the Drupal site), though the option is disabled by default.

There are a few situations in which you'd want to issue a mass password reset in calmer times. Just before launch, for example, you might want to ensure that a large batch of users migrated from another system all select new, secure passwords. For the most part, though, Mass Password Reset is a good tool to keep in your back pocket for a time when you need it. Hopefully you won't, but it's great to have when you do.

*/
Jan 28 2013
Jan 28

Node Access: Who wins?

While Drupal has always had a pretty robust access control mechanism, it was difficult in the past to handle multiple contributed modules who wanted to impose different types of access control. Who wins? If a node is within a private Organic Group, but is also in a public Forum, is the node private or public? In Drupal 6, multiple access control modules could conflict and had to take special care to co-exist. It was messy.

In Drupal 7 the access control API was cleaned up and now it is relatively easy to handle multiple access control systems. Let’s learn the best way to implement your own access control system in Drupal 7.

The Perils of hook_node_access

Drupal 7 added a cool new hook for developers: hook_node_access($node, $op, $account). On the surface, this seems like the ultimate hook to control access. You simply return NODE_ACCESS_ALLOW, NODE_ACCESS_DENY, or NODE_ACCESS_IGNORE. In reality, this hook can be very dangerous! It allows you to override the access control of any other modules on your site. For example:

1
2
3
function mymodule_node_access($node, $op, $account) {
   return NODE_ACCESS_DENY;
}

This would deny access to all of your content regardless of any other access control. If it returned NODE_ACCESS_ALLOW it would *allow* access to all of your content! Unless some other module returns NODE_ACCESS_DENY, in which case access would still be denied.

Even worse, your custom hook_node_access function is ignored by Views, Menus, and other content queries on the site. Even though you have denied access to all content, you’ll still see all of your normal menu links, and will see your nodes listed in Views. Only when you click on a node to view it’s full detail page will you then be denied. You might be violating content privacy just by showing that certain content exists!

A “Deny” based approach

Drupal is a “deny-based” access control system. In other words, if anybody denies access to a node, then the node is blocked. This is similar to having multiple locks on your door: you need to open ALL the locks to enter your door. Using hook_node_access to return NODE_ACCESS_ALLOW access violates this convention and is generally a bad idea. Instead you should design your modules to DENY access when needed, and otherwise return NODE_ACCESS_IGNORE to allow other modules to decide if access should be granted. The hook_node_access results are the “last line of defense” for denying access and don’t stop Views or Menus from showing parts of the content anyway.

The correct approach is to use the Drupal “Grant” system. This API existed in previous versions, but in Drupal 7 it was cleaned up and works much better. The key hooks are hook_node_grants($account, $op) and .hook_node_access_records($node). The documentation can be hard to follow and talks about “realms” and “grant ids”. Instead, let me explain this API using the concepts of Locks and Keys.

hook_node_access_records are Locks

LocksThe hook_node_access_records is called to determine if a specific node should be locked. Your module has the opportunity to create a Lock with a specific “realm” and “id”. The “realm” is like the color of your lock and is typically the name of your module. This allows a single node to have multiple locks with different colors (multiple modules). To open the door, you would need keys that match each color of locks on the door.

Within a realm, you can have multiple locks with different “ids”. This is like giving the colored lock a specific serial number corresponding to a key with the same color and serial number. If you have a key with the correct color and serial number, than all of the locks of that color are opened. To summarize:

  • Each lock Realm (color) must be opened to access the node
  • Only one ID (serial number) within the Realm needs to be unlocked to open that entire Realm.

These node Locks are stored in the node_access database table, which means they are cached. This table is only rebuilt when you run the Rebuild Permissions in the Status Report area of your Drupal admin. When you save a node, hook_node_access_records is called only for the node being saved to allow it’s locks to be updated. If changing a node can affect the locks on other nodes, then you’ll want to call node_access_acquire_grants($node) to update the locks on the related nodes.

hook_node_grants are Keys

KeysThe hook_node_grants is called to create a “key-ring” for a particular user account. This is called dynamically at each page load to determine what keys the current user has. As mentioned above, a particular node can be accessed only if the user has the appropriate keys for each Realm (color) of locks on the node. Because this key-ring is not stored or cached, it is important to make your hook_node_grants function very fast and efficient.

When implementing hook_node_grants, you are typically only concerned about the Realm implemented by your module (remember that Realm is usually your module name). You probably don’t want to be messing with keys for other modules. Your hook just needs to decide if the user has any of *your* keys. Specifically, your hook needs to return a list of key IDs (lock serial numbers) within your Realm for the specified user account.

REAL Node Access!

The beauty of using the two Grant API hooks described above is that they are respected by Menus, Views, and optionally other queries within the database API. If the user does not have the proper keys to open the locks on a node, then the node will never display in any Menu or View. Unlike hook_node_access(), this properly protects the privacy of your content.

With Views, you can turn off the node access filtering in the Query Options of the Advanced section of the View. Turn on the “Disable SQL rewriting” option and now Views will return all results regardless of the keys and locks.

If you create your own database queries using the Drupal database API, you can also easily filter results based upon node access. Simply add a “tag” to the query called “node_access”. For example:

1
2
3
4
$query = db_select('node', 'n');
  ->fields('n', array('nid', 'title'))
  ->addTag('node_access');
$result = $query->execute();

The above example would only return the nid and title of nodes the current user can access.

UPDATED: It is important to include this addTag(‘node_access’) for ANY query that you perform that returns node results to a user. Otherwise you’ll be introducing a security hole into your module. You can also use EntityFieldQuery which automatically filters results based upon node access.

An Example from Open Atrium 2

In Open Atrium 2, we implement a flexible node access system. All content is assigned to a specific “Section” within a normal Organic Group. Each Section can be locked based upon Organizations, Teams, and Users. For example, if Mike and Karen are assigned to the “Developer” Team, and the “Developer” Team is assigned to a specific Section, then only Mike or Karen can see the existence of that Section and the content within it. To accomplish this, we implement hook_node_access_records to assign locks, and hook_node_grants to assign keys.

First, let’s assign the locks for content within a Section:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
/**
 * Implements hook_node_access_records().
 */
function oa_node_access_records($node) {
  $sids = array();
  // handle the Section node itself
  if ($node->type == OA_SECTION_TYPE) {
    if (!oa_section_is_public($node)) {
      $sids[] = $node->nid;
    }
  }
  // Now handle pages within the Section
  else if (!empty($node->{OA_SECTION_FIELD})) {
    foreach ($node->{OA_SECTION_FIELD}[LANGUAGE_NONE] as $entity_ref) {
      $section = node_load($entity_ref['target_id']);
      if (!oa_section_is_public($section)) {
        $sids[] = $entity_ref['target_id'];
      }
    }
  }
  if (empty($sids)) {
    return array();
  }
  foreach ($sids as $sid) {
    $grants[] = array (
      'realm' => OA_ACCESS_REALM,
      'gid' => $sid,
      'grant_view' => 1,
      'grant_update' => 0,
      'grant_delete' => 0,
      'priority' => 0,
    );
  }
  return !empty($grants) ? $grants : array();
}

For a Section node, we just grab the node ID. For pages within a section we grab the referenced section IDs. Once we have a list of section IDs, we loop through them and create a $grants Lock record giving our module name OA_ACCESS_REALM as the Realm (color), and the Section ID as the ID (serial number). This adds our colored Lock to the nodes that are protected within Sections, using the specific Section ID as the lock serial number.

Next, let’s build the key-ring for the user account (*Note, this is a non-optimized version of code for instructional purposes):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
 * Implements hook_node_grants().
 */
function oa_node_grants($account, $op) {
  $sections = oa_get_sections();
  // returns a list of all section IDs
  foreach ($sections as $sid) {
    // determine if the user is a member of this section
    if (user_in_organization($sid, $account) ||
      user_in_team($sid, $account) ||
      user_in_users($sid, $account)) {
        $grants[OA_ACCESS_REALM][] = $sid;
    }
  }
  return = !empty($grants) ? $grants : array(); }

For each Section that the user is a member of, we return the Section ID for that Realm in the $grants array. If a particular node has Section locks, only users with a key to that Section will be granted access. For example, if a node has locks for $sid 1, 2, and 3, but the user only has a key for $sid 4, then access is denied. But if the user has a key for $sid 1, 2, or 3, then access is granted. You only need a single matching key within the Realm to grant access.

Conclusion

If you think about the Drupal node access system as a system of Locks and Keys, then it’s pretty easy to understand. It’s a very powerful system and one of the key strengths of Drupal. Try using this Grant API and only use the new hook_node_access as a last resort, especially when building other contributed modules where your hook_node_access might conflict with other modules.

Sep 27 2012
Sep 27

Lullabot's Drupal training site turns 2

It's been almost 2 years since we launched Drupalize.Me and I'd like to take a moment to appreciate some of the site's recent accomplishments.

Over 600 Videos

A few weeks ago, Drupalize.Me product manager Addison Berry announced the 600th video posted to Drupalize.Me! Members now get access to over 233 hours of content on an immense range of Drupal-oriented topics from simple content creation to site building tricks and database server performance optimization. Drupalize.Me's most popular videos cover coding for and using Views, using the Calendar and Date modules, configuring WYSIWYG editors, Display Suite, Organic Groups, Drupal 7 module development, and more. The Drupalize.Me team has been really amazing – posting new videos every week and paying close attention to member requests for new topics.

Over 2,000 Subscribers

Word about Drupalize.Me has spread and I often see people on Twitter telling one another that for them, Drupalize.Me has become the way to learn and keep up with Drupal techniques. Drupalize.Me has iPhone/iPad, Android, and Roku apps so members can watch the videos on their mobile devices or televisions. Drupalize.Me has also partnered with Acquia to offer discounted memberships to Acquia Network subscribers.

As word has been getting around about Drupalize.Me, subscriber numbers have been growing and recently crossed 2,000 simultaneous subscribers. We're reaching more people on a monthly basis than most large-scale Drupal events. We couldn't be more excited about the response!

Drupalize.Me now has a staff of 3 full-time people creating videos, maintaining the site, adding features and handling customer support. This team is augmented by others at Lullabot who step in to help with expert video training, development, design and support. Drupalize.Me now represents more than 15% of Lullabot's budget and has become a great outlet for the Lullabot team to share the knowledge that we've gained building the high-profile websites that represent the majority of our work.

New Features

The Drupalize.Me team has been listening closely to subscriber feature requests and we've gotten lots of new features over the past 2 years. They've arranged videos into "series" collections and allow users to watch them consecutively. They've also added curated "guides" collecting videos into linear curriculum for different types of members. They've also greatly improved the user dashboard pages allowing users to manage their queue as well as see the listing of recently watched videos and even displaying a line graph so members can see their progress within the videos they've watched. The team also added the ability to store pause points and allow users to resume from exactly where they left off - even if they're resuming on a different device such as their phone or connected television.

And speaking of connected televisions, we've got apps! We've got an iOS app for your iPhone/iTouch/iPad which can AirPlay to your AppleTV. We've also got an Android app and an app for the Roku Streaming Player box. You can pick up a Roku box for as little as $50, hook it up to your television, and watch all of the Drupalize.Me videos from your couch. It's a great way to learn.

Group Memberships

Drupalize.Me also offers group memberships. If you want Drupal training for your entire group, department, company, or institution, we offer that too. Group accounts greatly reduce the price of individual accounts while still allowing each group member to manage their own video queue, resume videos, and see their own history. We offer both managed group plans and IP-range plans to allow access to all devices at a physical location such as a library or campus.

Subtitles, Transcripts & Translations

Perhaps the greatest new features at Drupalize.Me are the ability to offer subtitles, transcripts, and translations for the videos. We have many international subscribers who, while they speak and understand English, sometimes can't keep up with the rapid-fire technical information in the videos. They've been asking for English-language subtitles and transcripts so they can follow along better. We're proud to say that we've added this functionality as well as functionality to provide complete translations with subtitles in other languages! 60 of our recent videos as well as the complete Introduction to Drupal guide already have transcripts and subtitles. And all new videos published on Drupalize.Me in the future will have transcripts and subtitles.

We're currently looking for volunteers to do foreign language translation for Drupalize.Me. If you're a bi-lingual Drupalist and you'd like to help make bring these Drupal training videos to the world, please contact us!

Drupalize.Me & Videola

One of the Drupalize.Me team's biggest accomplishments is building the Drupalize.Me site itself. The team has built a great Drupal-based platform which manages both the permissions and delivery of adaptive bitrate streaming video; recurring subscription billing and administration; video content categorization, listing, and organization; mobile app and IPTV delivery with seamless pause-on-one-device-resume-on-another functionality; and now even multi-language subtitles and transcripts.

As we've been building Drupalize.Me, we've been funneling this work and knowledge into Videola, a platform to provide this functionality to others wanting to build subscription-based or IPTV-oriented video sites. In short, Videola is a framework for building sites like Drupalize.Me... or like Netflix, Hulu, or Amazon video-on-demand. Videola can do everything that Drupalize.Me can do and more. If you'd like to build a site like this, please contact us and we can talk to you about getting you set up with a Videola site of your own.

Onward

Addi and the rest of the Drupalize.Me team have been doing a lot of training at DrupalCons, DrupalCamps, and other events. They've been very involved in the Drupal Ladder project and have posted a series of free videos to help new Drupalers get involved with core development.

Drupalize.Me recently started its own podcast (which picks up where the long-running Lullabot Drupal Podcast left off). Every other Friday, the Drupalize.Me team is posting a new podcast with interviews and discussions to help listeners keep up with the ever-changing world of Drupal. The team is also constantly upgrading and improving the site and they've got lots of great feature ideas for the future.

I couldn't be more proud of the work that's been done by Addi Berry, Joe Shindelar, Kyle Hofmeyer, and everyone who's helped with Drupalize.Me over the past 2 years. The site just keeps getting better and better. At this rate, I fully expect that 2 years from now I'll be bragging about their Drupal training neural implants and interstellar 3D streaming. But for now, I'm really happy with where we are – doing great, having fun, and sharing knowledge with people, empowering them to do great things.

Jul 09 2012
Jul 09

For Humans and Androids

Out of the box, Drupal includes many useful features that are helpful for sites where one person wears the developer, site builder, and content administrator hats all at the same time. However, some of these features could be considered dangerous when a broader group of individuals are administering a Drupal site. The Paranoia module aims to help keep your site secure by disabling places where PHP code might be executed or important data might be changed.

Installing Paranoia follows the usual steps for any other Drupal module; download to sites/all/modules, and enable it from the modules page. If the PHP module is enabled on your site, you will be warned that such content will now be "plain text" and should be audited.

PHP module and text filter is disabled

Other changes that the Paranoia module makes include:

  • Only letting user 1 (the site administrator) edit the user 1 account
  • Disabling using PHP for block visibility
  • Prevents disabling Paranoia without direct database access (or using Drush)

By default, Drupal 7 permissions tagged as being "restricted access" are prevented from accidentally being added to anonymous or authenticated users. As well, permissions exposed by other modules can be hidden entirely by implementing hook_paranoia_hide_permissions().

Paranoia is a great example of a short and simple module that gets the job done. If you're running a site where you're sharing administrative duties, consider installing it to increase your site's security.

*/

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web