users editing their own CSS and security

hi all,

im trying to make my site as customizable as possible for its users, and am currently pulling my hair out trying to workout the regexs to allow them to edit their own CSS from an online form.

of course, it would be nice and easy if i could just bring up their CSS in a <TEXTAREA> and let them make changes and save it...but i wonder, is there security issues with this?

all users are behind htaccess, so its not like every script kiddie is gonna be in having a go at compromising my server....any ideas, either on this, or on a tidy method of achieving this result are appreciated.

heres the vibe at the moment

(i) script reads a config file, which contains name/value pairs of the changeable elements in the CSS.

(ii) script prints a form using name values as <INPUT> name/values

(iii) when user submits the form, the script opens a template of the full CSS, reads it into an array - replacing specific tags with the values from the form.

(iv) script open users CSS and spews the lot over the top


while this reads easy, it looks like a dogs dinner in code


cheers

I'm not a security expert, but I don't think using a big <textarea> to have them edit their own CSS file would be any more insecure than using a text input field to let them edit an individual style element. Any harm they would do in the <textarea> could be done in the <input> as well. Furthermore, it's really not a security issue at all that you should be worrying about since it's a CSS file. I'm not sure if I'm saying this correctly, but CSS files aren't like Perl files in that they aren't server ran an excuted. They are just read when displaying an HTML file. If anybody puts in any weird (or harmul) characters or words in the big <textarea> I don't think it would be a security issue. It would be more of a "would-it-still-display-correctly" issue. In IE if there are mistakes, I think they are just ignored, but Netscape seems to be more stringent.

With all that said (not very eloquently I must say), I do have a way to make everything secure. You will just have to set all the options. The suer will have all the options with my idea if we're just talking about colors, but if you're talking about fonts and other things of that nature, it will be a bit less "option-ful". What you would do is for each color attribute create 6 tiny <select> fields of one character each (0-9 and A-F). And give them all the same name. If you use CGI.pm all 6 characters will come in as an array and you could use the join command to make them into a scalar variable when you parse it. For example:

That would do it. I don't know if it'll work anything besides CGI.pm. Now this form would be very time-consuming to make (although there are ways you could make the script do most of the work), but it'll be very secure and it'll still give them all the options for any color. Now as for the font issues and other things like it, you'll just have to give them a set list of fonts (or whatever it is you're working with). Just think of as many possibilities as you can and go with that.

That's basically it. I hope that gives you ideas and you can work with that. If you need any more help just reply and I'll be glad to do my best to help.

Actually, there are significant security risks associated with allowing users to enter free text that will be render as plain HTML (which CSS will be, unless you plan on linking in the style sheet).

Do a google search for "cross site scripting attack," which is when a user enters malicious script tags that get rendered in a browser. This is one of the more common hacks out there, and potentially VERY damaging.

Here's a nice little primer-
http://www.perl.com/pub/a/2002/02/20/css.html

sorry about the delay responding...i didnt get an email???

nice idea benahimvp - i hadnt considered that the array of similar named form elements would apply outside radio buttons - i suppose a <SELECT> box would do for text, style, size etc....


Hero, the CSS will indeed be linked...i wasnt sure if there was some way they could just type a script into the textarea instead or something......
thankyou for the primer, i thought that stuff was restricted to appearing in the HEAD of a document...bummer.

so a linked CSS is OK? Im not sure i see how?

this is becoming less and less a perl question

in terms of display, if they f*** it up, then its only their view of the site that is effected.....each page dynamically generates a link to the users CSS file on the server....and with an option to restore to default settings, i figured this would be pretty fool proof.

maybe this is just a nice idea, that isnt worth the hassle.

On a similar note, if your going to parse out html tags etc, whats the general perl approach to putting desired ones back in....like the formatting tags on this forum.

my method seems far too complex, which ive found....with perl at least...this means your doing it wrong!

replacing <B> is easy......but what about a link, which has more than one property?

cheers guys

I'm not quite sure i understand your last question.

So you want to do a VBB type system where people can enter formatting tags?

I personally think that these are usually kludgy systems devised because the author's don't know the true joy of HTML::Parser, and my current favorite, HTML::TagFilter. Why make folks learn another markup system, when you can easily and safely allow them to use the specific parts of HTML that you want?

With HTML::TagFilter, you can RELIABLY (the key here) set up a filter that only allows the HTML tags and attributes that YOU want folks to be able to use.

Check out
this thread here at www.perlmonks.org. Basically, you set up a ruleset of what you allow and deny, and HTML::TagFilter does the rest for you. Here's my example from that thread-



What this filter does is allow p, i, b, code, br, u, and pre tags with any attributes, allows img tags with any width, height, border and src attributes, and a tags with any href, target, and name attributes. All other HTML is nixed. You can then pass HTML to be filtered through the filter_html() sub (as a scalar) to be processed.

This works REALLY slick, and I really can't think of an easier way to do this. It's also very reliable, because it uses HTML::Parser for all the heavy lifting. HTML::TagFilter ROCKS.

hero, this is exactly what im looking for....id read the HTML:Parser et al stuff....but it seemed to be coming from a different angle - extracting HTML from a document...not replacing HTML into a document.

"kludgy" was a very apt description of my system

ill be checking that out further....it did occur to me that if someone was going to learn 'my' system of writing tags...they might as well learn the HTML way.

can the tag parser force, for example, a link to be "_newwindow"...s'pose ill just have to suck it and see.


thanks again.
liked the slashdot article on CD burning - wait till they get a load of us!


mucho gracias

Don't forget that css, even when linked from an external file can contain so-called executable material. Some, such as the background-image property allow the loading of files from local or remote locations, with the URI('location') syntax.