drupal 6 - what's the worst that can happen with 'full html' access for users?
zilla - February 20, 2008 - 23:03
so i don't mean to draw crazy attacks here but i'm wondering what the worst thing is that can happen if registered users have access to full html across the site for submitting (blogs, pages, stories, etc)...it obviously makes it easy to embed videos from video sharing sites (which is why i have it up that way) - but what's the worst in d6? could somebody take down the site? infect users? embed horrific scripts and so on? if so, is there an easier way to allow for users to embed videos from 3rd party sites in d6 (some modules aren't there yet, so wondering about right now/this month)
thanks in advance for any advice, feedback etc
XSS
with full HTML, users can put whatever scripts they want into your pages, such that anyone who visits any of those pages can get hacked in all sorts of evil ways (stealing cookies, setting up keyboard loggers on their machines, the sky's the limit).
http://en.wikipedia.org/wiki/Cross-site_scripting for more info...
Just add ...
Add the tags you want to the allowable filters in the "filtered html" profile. That way your users can post videos without opening you up to Javascript vandals.
i disagree
don't just add the tags you want. for example, lots of people like to suggest "just add
<img>so your users can imbed their images". the problem is that the "image" that's auto-loaded via this tag can be an arbitrary URL, including a web page with javascript that does the same evil things they'd do directly with<script>. ditto lots of other tags that aren't in the default list of allowed tags.so, don't just go adding the tags you want to your allowed tags list, or you end up with something just as insecure as full HTML. :(
the better course of action is to understand the security implications of each tag. if it's possible to use it for bad things, give your users another field (thanks, CCK) that you can validate separately to ensure it's legitimate and then embed whatever tags around that input via your theme to make it work.
there are probably a bunch of contrib modules that already do this for you, but i'm not familiar with them yet.
good luck,
-derek
thanks, that's what i thought..
thanks to all of you for the feedback - and i was thinking the same thing with the img tag, seems just as easy to pull in an external page or vile image...
really this was just for video, so it sounds like i should wait for a more stable release of the video embed modules (youtube etc) -i think there's one close to complete already...
No
Where did you get such an utterly wrongheaded idea? Web browsers do not load and process HTML or Javascript from an img tag. Doesn't happen, period.
Any time you allow users to embed media in pages, you run a risk of them embedding something inappropriate. A tool like the embedded media field module lets the admin determine which remote sites to trust, and helps avoid the problem of users entering malformed tags (and not getting anything to show up at all).
But there is NO risk of them embedding Javascript through an img or object tag, period.
Utterly right
Try this, for example:
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">I see the alert on Safari3, and FF2, and I bet you'd hit it on many other browsers.
For more, see:
http://ha.ckers.org/xss.html
http://drupal.org/node/224921
HTML Purifier fixes this
HTML Purifier fixes this. What's happening here is that you've got some invalid HTML, and if someone doesn't clean up for standards, it's field day with browser behavior. But if you sic your own parser on it, and then output it again, you don't have a problem with that sort of thing.
I don't know if filter HTML has problems with that code.
Now, there is an auxiliary concern of CSRF which can cause problems with image tags. However, problems here are due to sloppy web application developers and not the filter itself. Img tags can also be used to harvest IP addresses; this is intrinsic to the nature of the tag. If you don't feel good about that, you can always set %URI.DisableExternalResources to true for HTML Purifier.
Darned kids!
I mistakenly had Full HTML turned on for comments on my site, until recently when some rapscallion turned a whole page on my site green through mischievous code in a comment. Rent my garments in vexation, I did, but a truly roguish miscreant could have dealt much worse...
Everyone out there, be careful of this! Watch what formats you allow users!
--------
A site by, of, and for the Drupal newbie: http://www.drupalace.com
(?)
how does the HTML Purifier module handle the inputted code? can it be trusted?
and does allowing images thru bbcode cause the same security holes? in that case i would prefer to stick with html.
Purifier
As I posted earlier, image and object tags do not introduce a cross-site scripting risk.
HTML Purifier does a thorough job of cleaning HTML and ensures that it is valid. Invalid HTML isn't just a geek issue; some invalid HTML can interfere with page rendering.
For example, if you allow the table, tr and td tags, and your underlying page layout is based on tables, a slip of the finger on the part of a user can cause your page layout to blow up. Purifier will clean up that mess and you'll never know there was a problem. (Several other modules also will clean up tag asymmetry.)
HTML Purifier does guard against cross-site scripting, but as previously explained the "Filtered HTML" default does not allow script tags to pass anyway.
I'm using HTML Purifier on one of our websites where complete beginners are tinkering with HTML, and it's a comfort to know that they can never break anything.
Wish you were right...
image and object tags do not introduce a cross-site scripting risk
They absolutely do. See "Utterly right" above. Sorry to break your world view about trusting img tags, but someone had to do it.
an update: what i decided to to instead...
okay, so after worrying about some of the problems touched upon here, i decided to allow the IMG tag in filtered html, disabled full html for users and instead uploaded a video module for drupal6 (basically only supports youtube, googlevideo and 'godtube' [interesting 'top 3' list from the dev ;)]_
this resolves the core scripting issues, and while img opens up a few new ones i'm willing to deal with it on a case by case basis, provided there aren't 2 million cases per day...
Bad move...
i decided to allow the IMG tag in filtered html
See above... :(
don't forget csrf
img tags (among others) also make it easy to exploit a "cross site request forgery" http://en.wikipedia.org/wiki/Cross-site_request_forgery
If there is a csrf available then allowing img tags for anonymous or untrusted users makes it easy to exploit the csrf. That's true both for csrf on your site and on any other site that has a csrf hole on the internet.
Since Drupal contributed modules (and sometimes core) occasionally have csrf attacks allowing untrusted users access to the img tag can open your site to abuse.
--
Open Prediction Markets | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
i hear you - img is restricted
for now only registered users can even upload images, so i'll have to roll the dice and see how this goes...not sure if there's an alternative for image handling that will allow for what i want to do (put images into blog postings, allow for placement of images, etc)