Forum OpenACS Development: Security parameters in kernel

Collapse
Posted by Malte Sussdorff on
I want to create a TIP to enlarge the default security parameters to the following values due to our support of HTMLarea.

AllowedAttribute: href src color align alt face size style title name nowrap cellspacing cellpadding valign bgcolor

AllowedTag: FONT STRONG BR SPAN B I P A LI OL UL EM BR TT  BLOCKQUOTE CODE PRE FIRST_NAMES LAST_NAME EMAIL GROUP_NAME H2 H3 H4 DL DT DD TABLE TR TD TH SELECT OPTION SMALL

Please give feedback so we can create a good and not too insecure TIP out of it.

Collapse
Posted by Jade Rubick on
Those seem reasonable to me. I don't think we want IMG, but that's not there. Note: we cannot enable HTMLarea until it has Safari support :)
Collapse
Posted by Don Baccus on
I'll let people with more security expertise than me comment on the actual list of tags but ... It's a bug for the preview feature to automatically throw you into spellcheck/html mode ... if I say I don't want spellchecking, by golly I don't want spellchecking. And if I'm not doing HTML, I don't want my preview in HTML.
Collapse
Posted by Ben Koot on
Maybe I am missing something, Wouldn't the IMG tag allow us to import pictures from photodb that autogenerates an image display url into the modules like etp and blogger? With weblogs gradualy replacing traditional homepages, it's to bad OACS doesn't allow the use of images in a simple format. If Movable type and other systems can handle this, and given the fact we have good way of storing pics on the web with photodb, it seems a bit strange other parts of oacs don't allow the use of images. It's though to convince potential clients to use OACS if security prohibits issues that people regard as pretty straight forward. Just a thought Ben
Collapse
Posted by Malte Sussdorff on
The moment we allow image tags I'd immediately revoke Site Wide Admin from all people. Though they are a nice feature Ben, they open up a place for attacks that has been discussed quite a lot and especially with a site where anyone can post, this is a critical security issue. Take into account that I can put any URL in an image tag, including the one that gives a certain user_id SWA access.
Collapse
Posted by Matthew Geddert on
I would add the following to that list:

H5 CITE TBODY

Htmlarea sticks tbody in to tables so without it htmlarea tables are pretty useless. Cite is used to site people and expected by w3 "standards" and H5 since some people might want it. so if you are using html area for tables its pretty much needed. I will also list the ones I know are NOT good:

SRC

If you put this in there people can do nasty things by posting non-existant images and when a logged in admin visits that page it does the bad stuff. Which means that an IMG tag can't be used. One way of fixing this, is verifying that the link is a valid link to a photo in the photodb... but without image validation it can't be allowed.

I would remove:

OPTION SELECT

People won't be creating forms in htmlarea (hopefully). Tags such as FONT are only acceptable if we also allow a number of attributes "such as size, etc." So if that is enabled you would also need to come up with a list of attributes we want to enable. HTML area assumes you can enter cellpadding with its tables, so in order to have a "seamless" experience you would need to add a lot of attributes to this list.

HtmlAREA is a "beast" to deal with for a website that you want to follow standards of appearance. People assume they can copy and paste from Word, etc. and they can't since those programs add various things such as style, class, and other not allowable attributes. These attributes shouldn't be allowed since it would let users mess with the appearance of your site (which is also a security issue). And html area doesn't remove not allowed formatting out of the box the way people expect it to (i.e. like Word).

If you want to for example not allow users to use underline (which you don't have in your list and i approve since underline should only be used for links), copying and pasting from word sometimes put in unused (not visible underlines) that had been there but were deleted. I tell my users that if they need to post a word document i need to do it (by cleaning it) and then they need to edit using only html area. It would be really nice if we had a way of stripping code that isn't allowed away from somebodies post and giving them a preview of the output, after stripping it to what is allowed (or making "logical substitutes" - i.e. a FONT size is large could be converted to a STRONG.

Collapse
Posted by xx xx on
I would like to add:

to the list of tags:

ABBR ACRONYM

It is mark-up for those using speachsynthesizers.

to the list of attributes:

accesskey

to allow jumping to links by using the keyboard

I cannot comment on security, maybe Jeroen can. I know we should disallow all attributes/tag combo's that invoke (java)scripts obviously.


WebCT:
http://www.securityfocus.com/bid/10357/discussion/

An approach:
http://www-106.ibm.com/developerworks/linux/library/l-sp2.html
http://www-uxsup.csx.cam.ac.uk/redhat/howto/Secure-Programs-HOWTO

Collapse
Posted by Don Baccus on
Ben, note that there's nothing preventing a particular site admin from allowing use of the IMG tag, if they're willing to accept the security risk. We're not talking about what you're allowed to do in the OpenACS toolkiet - we're talking about what you're allowed to do BY DEFAULT, without changing the tag security parameter ... that's all.
Collapse
Posted by Ben Koot on
Hi folks, Thanks for the explanation. I get the point now. Ben
Collapse
Posted by Ben Koot on
I think I found a workaround, posted in BT https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=2208

Ben

Collapse
Posted by Rafael Calvo on
Hi
where in the documentation is it described what the webmaster needs to do to allow images?
I thought it was in the kernel parameters
Collapse
Posted by Derick Leony on
It is in the kernel parameters AllowedAttribute and AllowedTag (Antispam section).
Collapse
Posted by Gustaf Neumann on
Malte, a few of the tags mentioned in your original posting seem to be a result of cut&paste from word. I would not move these to the allowedTags but rather recommend to use the msoffice-clean functions of newer incarnations of htmlarea such as xinha.

The core of the discussion is that one can implement very nice functionalities (which would be quite important to provide good content creation tools for oacs/dotlrn) by being more liberal; for example, i have developed an html-area-based wiki of the last days, but without images it wont be as nice as it is now.

In general i agree that for the toolkit the conservative (non-liberal) approach should be standard. At the same time i think we should provide options for site admins to configure their system to be in certain situations more liberal by:

  • permission checking for potentially unsafe allowedHTML properties
    (certain users are allowed to use potentially unsafe HTML-Tags)
  • define parameter with regexps for trusted (partial) URLs for hrefs, img-src, link, applet ...
    i do not see currently the danger of including images from e.g. the icon library administered by the sysadmin.
  • check urls for untrusted charactes, patterns etc. to prevent javascript invocations.
A combination of the frist two options seems to provide a good deal of protection, the last option should be done always (we do this via pound anyhow).

Btw. there is a recent article about cross site scripting that demonstrates creative ways to use css for exploitation
http://www.betanews.com/article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391

Collapse
Posted by Dave Bauer on
I think using permissions to check who has permission to use certain tags is a good idea.

On many sites I work on, a site wide administrator manages the content pages and can be trusted to enter safe HTML. We would still want to security check HTML entered by regular users in forums, weblogs etc.

We already have an allowed protocol parameter that can be used to check URLs for unsafe options such as javascript.

I think checking images for valid URLs such as those internal to a site also makes very good sense.