I would like to allow my webapp users to save custom CSS through a text field to modify the look of their GUI.
I guess there are some evil CSS hacks out there. What should I take care about?
+7
A:
One solution would be for you to provide the user options through some editor, allowing them to pick colour/size of various elements. Then generate the CSS yourself based on the options the user has provided.
This would prevent any nonstandard CSS, or CSS you do not wish to use to be saved.
Zeus
2009-11-27 14:26:30
+1, exactly what I was thinking :)
ILMV
2009-11-27 14:27:28
Good answer. Don't forget you still need to validate all input! If it's a colour, make sure it's 3 or 6 hex digits and not `fff;font-size:500px`
DisgruntledGoat
2009-11-27 14:35:40
Or, if you embed it in the HTML page, `#fff;}</style><script src="badone.js"></script>`.
Boldewyn
2009-11-27 14:44:23
A:
If your users may only modify their very own CSS and not the one of other users, what's the risk? The CSS will only be served to them, so in the worst case, they'll be able to hack themselves, no?
Jerome
2009-11-27 14:33:01
+1
A:
Among things others said, check if they are valid CSS: http://jigsaw.w3.org/css-validator/
marcgg
2009-11-27 14:35:11
+3
A:
If you are allowing users to directly include custom-built CSS on your site, you are asking for hackers to take it over. You are actually making the theming system less usable, because only people that know CSS are able to do this. Unless your site is specifically for web-based programmers, it's probably best to make a set of themes that the users can choose from instead.
You can also make a set of tools on your site that allow the user to change specific styles on the page through a user interface instead of directly through CSS. This will allow more users to more flexibly style their pages, but it usually comes at the cost of more development time - unless you're using a CMS, and your particular CMS allows this functionality easily in the core or in a plugin.
Hope this helps.
monokrome
2009-11-27 14:36:29
I'm not quite sure, why it would be an invitation to crackers. If you store the CSS in a database (properly quoted) and deliver it embedded in the HTML (properly encoded), *and* deliver it only to the one who uploaded it, then what's the security hole?
Boldewyn
2009-11-27 14:43:13
Firstly, security holes comes into play if other users get access to their page. For instance, there are phishing attacks on MySpace that ask for a person's password and following that turn their page into a giant div that redirects to the phishing page on click. This page is later turned into a redirect to market another page via people's myspace.Secondarily, you will have people who screw up their pages (maybe with a div taking up the entire page size?) and want you to fix it.However, if nobody else sees their page - there is a minimal chance of errors. I am the type who wouldn't risk it
monokrome
2009-11-27 15:12:13
A:
Although I would go for Zeus' answer, you could use a CSS parser (search SO, there are various questions) and check all input against a list of approved properties (color, background, etc).
DisgruntledGoat
2009-11-27 14:39:27
+3
A:
There's exactly one thing, that I could think of: CSS expressions (that are, however, only evaluated in IE). These allow for JavaScript in CSS files, so I would strip anything like
property: expression(...);
or simply throw an "Not allowed" error.
But then, if you deliver the CSS back to exactly the user that put it in in the first place, he is responsible, if he himself introduces an XSS vulnerability.
In any other case: Use Zeus' solution.
Boldewyn
2009-11-27 14:40:22
There's one additional vulnerability, and that's with referencing files for background images, etc. I know there are CSS tricks people use to get around the same domain restriction of XHR by making a request via a background-image or whatever. So if you're going this route, you'll probably want to exclude any CSS rules like "url()."I'd agree that the best solution is to not make it free-form, have the user specify inputs on a per selector/style basis. That's not coding, but much more secure.
Bialecki
2009-11-27 15:20:06