Input formats - the quickest way to make your site insecure
Heine — Sun, 30/12/2007 - 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'.
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:
$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.
Very good point!!
Pedro (not verified) — Mon, 31/12/2007 - 00:21Im going to check my site now! XD
btw...
$GLOBALS['user']->uid = 1;
Wow, this is scary. Thanks
Anonymous (not verified) — Mon, 31/12/2007 - 00:57Wow, this is scary. Thanks for the heads up.
Don't get scared it doesn't
sivaji (not verified) — Sun, 26/07/2009 - 22:58Don't get scared it doesn't works :P
It sure does
Heine — Sun, 02/08/2009 - 20:27Please don't confuse "I cannot get it to work" with "It doesn't work" ;p
Yet another popular pitfall
venkat-rk (not verified) — Mon, 31/12/2007 - 15:18Confused about this one. Did you mean, "Yet another popular pitfall is to enable the HTML filter...."?
Thanks.
HTML Filter
Heine — Mon, 31/12/2007 - 15:37The 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
Anonymous (not verified) — Thu, 31/01/2008 - 04:07even though it was really creepy being notified of this, i appreciate it. thanks.
Wow
Michelle (not verified) — Thu, 31/01/2008 - 05:21Scary 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
Anonymous (not verified) — Fri, 01/02/2008 - 11:45Oh 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
nato (not verified) — Tue, 12/02/2008 - 19:51Thanks 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
Heine — Sat, 23/02/2008 - 14:22The 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.
Great
DynV (not verified) — Mon, 30/06/2008 - 22:35Great tips ! I was already weary but now I'll be paranoïd. :D
Wow. That's a very quick way
camaros (not verified) — Mon, 06/07/2009 - 20:08Wow. That's a very quick way to be exposed. Thanks for showing us this so we can be aware of it and make an attempt to address it.
Post new comment