Is it safe to put tag in filtered html for users? Under Allowed HTML tags?
Better safe than sorry i say. So i ask here. Are there any drawbacks?
Thanks for replays.
Subscribng, interested in answer of this also!
But suppose a user sets this for an image:<img height="150000" width="9999000" src="http://mysite.com/...../files/images/image.jpg" />
<img height="150000" width="9999000" src="http://mysite.com/...../files/images/image.jpg" />
A 150 thousand pixels height and 9 milion pixels width image in your page !
http://www.moriasnow.grReliabilityConsistencyFeedback ------ NeverAchievable -------
ReliabilityConsistencyFeedback ------ NeverAchievable -------
Looks like nobody knows. Or at least doesn't find these important. ;)
Searching a bit i found that allowing the img tag is not secure !
I found these:http://drupal.org/node/224599#comment-742203
see also the link provided for Cross-site request forgery in http://en.wikipedia.org/wiki/Cross-site_request_forgery
And when you limit the user image upload size as stated on: http://drupal.org/node/100319#comment-204253?
Is then still unsafe?
Here i found some things talking abaout resizing:
It is for drupal 5. But probably the same for drupal 6. So some code in comment.tpl.php could handle resizing.
So good examples of these code could solve some issues we pointed here.
Another question. In comments we should use only use xHTML < img > tag with /> closed tag too? Plain HTML < img > tag breaks the markup?
So these is another important thing i guess. Only xHTML way is good enought. Basic HTML in Drupal wont work right?
I noticed these when my markup behaved strange when i had < img > tag without ending /> tag in post.
So these is not good enought in posts:
We must always do it like these:
Still haven't decided yet. Any suggestion on what module or what method to use for handling hotlinked images?
Thanks for replies. I am opened to any suggestion that works good and safe.
Can I ask a question about this security stuff?
Instead of allowing users to input html directly, I have chosen to use a wysiwyg editor (FCKEditor). In the first instance, it doesn't allow any html at all. If you type html or script into the text area, it simply renders as normal text. So it is basically acting like a blanket 'no html' filter. Secondly, the html for the page is input using buttons or dropdowns, which means that input is controlled - users cannot input malformed html. Thirdly, the drupal filters are set to only allow the tags which the editor uses when creating the source of the page.
So is allowing users to embed videos and images through a wysiwyg editor less of a security risk than the risk being discussed in this thread, from allowing users to write their html source directly into the text box? Or do the same risks exist?
Everything I say is opinion, even if interpreted as fact.
Sometimes I may be inaccurate or *GASP* wrong!
Sometimes I attack Drupal due to frustration. Get over it.
Yes but what is stopping users to close the wysiwyg editor and use plain input textarea?
About filtering html tags. Drupal does this by defoult. I tested. It just doesn't display tags that are not on the list. Evan if they are there.
WYSIWYG is just client side feature for "user friendly" input. It does not do nothing else.
> Yes but what is stopping users to close the wysiwyg editor and use plain input textarea?
With tinymce and fckeditor, at least, there is a choice for the admin to allow users to turn off the editor and/or edit the source directly. Both are choices though. If both are disallowed, there is no way for the user to switch off the editor or access the text area source, at least not without some sort of hack.
> About filtering html tags. Drupal does this by defoult
Both methods of letting user add media require that the tags be allowed. However, using drupal core means the source can be malformed and allows the security holes discussed in the above thread. With a text editor, it is not really the user who is allowed to use the html tags - the admin allows the *wysiwyg editor* to use those tags, and in turn the editor allows the user very limited access to those tags through fixed buttons and dropdowns.
Seems safe enough to me. But maybe I'm missing something?
The option you mention has a lot of bugs and is not very stable.
And what abaut if we use web browser in safe mode? What happens to wysiwyg editor then?
FCKEditor works fine.
I'm not suggesting a wysiwyg editor as a solution to the general problem (which seems to be that if you allow any basic tags *and* ability to write source directly into a textbox, then you open up the possibility of hacking. Moreover, this seems to be a general problem with the entire internet, not just drupal).
Rather, it was a question: if I use a wysiwyg editor, and therefore not allow direct writing of source, does that protect against the risks expressed in this thread. The answer appears to be 'yes', but I'm still not 100% sure. The reason I ask, is because my site is for a school, and I have 30 highly intelligent sixth formers who are probably all capable and willing to hack the site for a prank. Yet, if students are not allowed to include text-formatting, images and media in their content, due to a perceived risk, the site will lose most of its value.
I thought I was safe enough until I read this thread!
You may want to look at the http://drupal.org/project/htmlpurifier module.
==="Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu"God helps those who help themselves." - Ben Franklin"Search is your best friend." - Worldfallz
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
> And what abaut if we use web browser in safe mode? What happens to wysiwyg editor then?
I'll look into the html purifier module.
All this does leave me with a question though: considering many MAJOR websites allow users to add all sorts of media to the content, if these threats are are real, how come the whole internet is not failing and falling apart with these hacks? It seems to me that these threats must be very difficult to execute, and are only available to a few hundred people who actually know what to do to implement them?
I read my topic. And the topic http://drupal.org/node/224599 .
I searched modules and everything. A lot of google. And i decided i won't give my users image hotlinking option. When a trustworthy module or Drupal core will have these covered only then i will allow it.
I didn't found the solution for it jet so no image hotlinking for my users.
Probabbly a module which will use something like wysiwyg api + some editor which is synhronised with Drupal filtered html settings and that will filter the html tags better before writing to the database. And probabbly some bbcode input instead of html img input. That will output bbcode as html. Something like qoute module does for blockqoute tag.
And evan then a thumbnail creation would be needed in my opinion. And for admin some options to easy upload picture to the server. And a thumbnail picture to be as a link.
But i didn't found nothing like that for Drupal. And in Drupal 7 i think there will not be this functionality. So no images for my users. They will have to live with it and just paste links to the pictures and not images themself!
...that will filter the html tags better before writing to the database.
Maybe I'm not understanding what your looking for, but that's exactly what the http://drupal.org/project/htmlpurifier module does.
BUT it doesn't solve image hotlinking troubles. That is what i ment. But it is a usefull module i agree.
What if we use only BBcode tags and disable HTML "Escape all tags".
Is there any problem with these? Is it safer or the same in the end? The link stayes the same. How does BBcode module deal with it?
Thanks for answer.
I google a bit. The problem with img and bbcode img tags is that by defoult if i understand correctly somebody can write a php or other type script and names is picture.jpg for example. And then if we have it localy on server it can evan execute php code. If its not on local server than probably some XSS?
it's basically all the same thing whether you let users upload things to your site or link them to your site. There is always risk that someone may do something malicious. Show someone a 100% secure system and they'll show you someone who will find a way around that security.
Locks only keep honest people honest.
Yes but you see i found these right now:
I agree there is not 100% security but this feature is preatty strong. Don't you agree?
But if somebody could hide a php script inside picture.jpg file by simply adding different extension to the file then a lot of sites could be compromised if nobody would do nothing?
And what abaut comment upload module? Does it has this feature? A responible "administrator" of his page must ask him self this questions. Especially if he is a beginner!
Ok i think i solved these. I will use both BBcode and filtered HTML for users. I will use BBcode filters only for images hotlinking and i will set the predefined width and height with bbcode filter. So [ img ] tags will output predefined size of images. I know they are not thumbnails but still better then nothing. In the future maybee there will be a module for comments that will be able to handle this better. But for now i will use these method.
Cross site referer forgeries are also a dangerAlso remember that VIRUSES can be embedded into an Image. Sorry BILLY GATES!
If you allow IMG tags, a user can add a referal to a web page that they want to try and lure you to, without you knowing.For instance- You wont see an image and you wont know that your browser is visiting another wbsite behind the scenes..
The only way to safely do this job is to implement a feed that will fetch the image, test it and then render it into the image tag.Like an IMAGE Proxy. A good PHP script can test the data, ensure that its actually an image, check and adjust its size and feed it to the page, from anywhere.
Ultimately having the image loaded to the same server is the easiest way and gives you the best control. I personally store all uploaed images in a data bae table, and all static images are served from a remote site for faster page speeds.
Here is the IMAGE PROXY idea..<img alt="blah blah" src="./scripts/image_proxy.php?showImg=1&imageId=1234" width="<?php echo $img_w[$imageId]; ?>" height="same idea" />You will need to of course store a reference to the images URL somewhere, XML file or Database.
I only just though of this idea reading these comments, but I am 100% sure it will work. You can (will need to) create a filter that will swap the images src with the reference to your proxy-script as well. A str_replace within a preg_match will do it..I'm only a newbie with Drupal, but have used PHP since version 3..If someone wants to try this, swing me a message of you get stuck. I'm fairly busy and don't really need this feature either. YET!
Here's a good resource about some vulnerabilitys. There's a heap of revelent data on XSS etc.http://www.webdirections.org/resources/douglas-crockford-ajax-security/Watch some of the presentations, their quite enlightening and valid..Always remember, your knowledge only goes as far as you look. GOOD LUCK!
Time is relative to the observer
"Is it safe"? Well, let's put that in perspective.
Is it _outright, guaranteed, 100%_ safe? No.
Is it _safer than unfiltered HTML_? Yes. Definitely.
So, given that adding to the input format list is a better option than just shrugging and opening the floodgates to all HTML, is there any way in which I can apply attributes to , whilst still retaining the protection of the filtering?
Adding to the filtered list puts the images in, but no attributes work. Adding doesn't make any difference. I'm specifically interested in either style or the deprecated align attribs, to allow text to smoothly flow round an arbitrarily placed inline image (added with ImagePicker) in a page.
HTMLpurifier, at first glance, is far too much of a ball-ache...
I add required styling to the sytlesheet.
Not all images are necessarily going to be in the same position or aligned in the same manner on a page. Think about a magazine layout, with some images used as text breaks, without text flowing; others left or right aligned with text flowing.
The layout should be defined by the author's preferences - not by restrictions in the software.
When setting up magazine style layouts, I usually work towards an actual designed "style guide". Letting an untrusted, untrained contributor loose with a WYSIWYG is a disaster. So don't do that.
Authors "preferences" still need to be limited by the authors actual skills in using the tools, and how much you trust them not to deliberately eff things up.
Sooo ... Use a style guide to define the general layout rules you choose to allow, and allow 'class' on them. The WYSIWYG editors allow you to add that at least. That's best practice, even in the old days of print layout. You define 'styles' then re-use them consistently, not just make up alignment rules by hand each time.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Yes, I can certainly see where you're coming from - and broadly agree.
I've been prodded into looking at this by looking at the ImagePicker module. _Lovely_ for nice easy ad-hoc add-image-to-page stuff, straight out the box. OK, so I've got to add image to Input Formats. Great. But... To use the alignment options it offers, I then have to either start fannying about inside the CSS or go straight to full HTML - and also need to modify the links manually, to include those styles.
Using CCK fields instead of letting users embed images directly helps a lot.
Drupal is a registered trademark of Dries Buytaert.