Input formats - the quickest way to make your site insecure

Heine —Sun, 2007/12/30 - 23:15

In a desperate attempt to balance my karma at the end of the year, a small public service post about the most popular way to make your site insecure. This is aimed at website administrators and developers. There will be no code (promise).

PHP

The best way to make your site and server an open playground for sociopathic script kiddies (including me) is to visit Administer » Site configuration » Input formats (admin/settings/filters), select the inviting radio button labelled 'Default' next to the PHP code input format and click 'Set default format'.

The Input format configuration page

A good second way to make your site insecure is to allow 'anonymous' or 'authenticated' users to use the PHP code input format. Just follow the 'configure' link, and fill all these empty "Roles" checkboxes that are just begging to be filled. Adding the PHP evaluator filter to a user accessible input format is yet another gaffe.

Now, when the Googlebot pays you another visit and updates its index, everyone googling for the presence of certain helptext in the filtertips will find your site. They can then leave or preview nice comments such as the following between <?php ?> tags:

// Okay, just this one line:
$GLOBALS['user']->uid = 1;

And Presto! they have administrator privileges immediately.

Full HTML

Yet another popular pitfall is to disable the HTML filter for input formats that are accessible to untrusted users (read: almost anyone). Now, users can embed ECMAScript or *gasp* Flash to make your browser do their bidding, should you ever view their comment.

If you think this is hypothetical; far from it. I used to google every month for these kind of issues and the harvest was always a rather pretty collection of sites. Among them various universities, open source projects, libraries and small blogs, but also (how ironic) a few Drupal shops and a number of sites dedicated to teaching Drupal. (Don't worry; I've mailed the ones I found).

Should you feel a little worried now; Good, go check your input formats!

For those of you who want to know more about input formats and how to use them, read Robert Douglass' excellent post Drupal Input Formats and Filters.

It's worth noting that the PHP evaluator filter moved to a separate module, disabled by default, in Drupal 6.

Comments

Very good point!!

Submitted by Pedro (not verified) on Mon, 2007/12/31 - 00:21

Im going to check my site now! XD

btw...

$GLOBALS['user']->uid = 1;

Wow, this is scary. Thanks

Submitted by Anonymous (not verified) on Mon, 2007/12/31 - 00:57

Wow, this is scary. Thanks for the heads up.

Don't get scared it doesn't

Submitted by sivaji (not verified) on Sun, 2009/07/26 - 23:58

Don't get scared it doesn't works :P

It sure does

Submitted by Heine on Sun, 2009/08/02 - 21:27

Please don't confuse "I cannot get it to work" with "It doesn't work" ;p

Yet another popular pitfall

Submitted by venkat-rk (not verified) on Mon, 2007/12/31 - 15:18

Yet another popular pitfall is to disable the HTML filter for input formats that are accessible to untrusted users (read: almost anyone)

Confused about this one. Did you mean, "Yet another popular pitfall is to enable the HTML filter...."?

Thanks.

HTML Filter

Submitted by Heine on Mon, 2007/12/31 - 15:37

The HTML filter (which is a filter that can be added to any input format) strips all non-whitelisted tags, and harmful attributes from content. Disabling the filter for user accessible input format means that <script> tags and event attributes (onerror onclick) pass through. You'd basically invite everyone to execute a cross site scripting attack against your site.

even though it was really

Submitted by Anonymous (not verified) on Thu, 2008/01/31 - 04:07

even though it was really creepy being notified of this, i appreciate it. thanks.

Wow

Submitted by Michelle (not verified) on Thu, 2008/01/31 - 05:21

Scary how many Google is finding. I contacted a bunch but there's way more than I have time for. Hope lots of people see this.

Michelle

Oh gosh, I mean every

Submitted by Anonymous (not verified) on Fri, 2008/02/01 - 11:45

Oh gosh, I mean every flavored Drupalista knows about the potential havoc that may be wreaked when carelessly throwing the PHP switch on, but who knew so many sites were making this mistake? And nice looking web sites even! I've notified a few people tonight, but regrettably, one man's good samaritan work can only go so far much. How can we make admins more aware of this common mistake?

Tony 'webavant' Zielinski

thanks...if only there were default input formats/role

Submitted by nato (not verified) on Tue, 2008/02/12 - 19:51

Thanks for the heads up! I wasn't paying attention and thought the Full HTML still stripped malicious script code.

The issue I struggle with is that I really want to set a default input format for each role, so anonymous users could get Filtered HTML and authenticated users (who might be using a WYSIWYG editor) could get Full HTML without having to choose it each time.

One could just add all the necessary HTML tags that a WYSIWYG editor would utilize to the Filtered HTML input filter I guess, but then one would have to remember to make changes to the input filter every time one made changes to what tags the editor utilized.

Default filters

Submitted by Heine on Sat, 2008/02/23 - 14:22

The desire for a per role default input format is a common one, as there are multiple contributed modules that try to implement this (see http://drupal.org/search/node/type%3Aproject_project+default+format).

The best approach for rich text editors (for now) is to add tags to the allowed tags of the HTML filter. In my experience, it's mostly anonymous users who need an RTE, whereas the editors are comfortable with HTML.

There's work underway for Drupal 7 that should improve the user experience when working with input formats.. Drupal 7 may ship with an RTE so it's imperative that the editor works properly with input formats.

Heine