views:

170

answers:

4

I'm new at php and I'm trying to figure out of this is a bad idea or a security risk.

I have a table of data that I provide to a user, it has a default stylesheet that it loads, but if the user wants to include their own, I've made it so they can just point to their stylesheet instead:

http://www.mysite.com/info.php?css=http://www.someothersite.com/mystylesheet.css

I've tried adding closing style tags and javascript in the css file, but the DOM seems to just load it as CSS that it isn't able to process.

I've never seen any other site allow this method of adding stylesheets, so, is this a good idea or bad idea? I was thinking that I could have the script load the file and look for key words used in javascript, but with my testing, I'm not sure that I need to do it.


Update: I'm adding the CSS as follows:

<link href="<?php echo (isset($_GET['css'])) ? $_GET['css'] : 'default.css'; ?>" rel="stylesheet" type="text/css" />
+7  A: 

So long as the stylesheet is used for their own account, and no one else's, then I'd let them do it. However, because it could be used to session-hijack someone (if they didn't logout) I would require the user's password to change the stylesheet. I also would force it to be stored locally.

Without a password all a hijacker need do is:

#selector:before {
  content: expression(getCookie('phpsessid'));
}

Obviously if you don't have a function called getCookie then they'll need to do more legwork, but it is still too easy for them to get the cookie data. This is why password protection of the custom stylesheet is essential.

If you don't include a field per-user, and use the $_GET['css'] route, then remember that it would be trivial to redirect a user from an external site (say MySpace) to their page with a route to a harmful CSS file for a hijacking attack. If there's no authentication that protects the changing of the CSS file, which should be password protected even when logged in, then your software is very, very vulnerable indeed.

The Wicked Flea
I don't have the file space to store all the css locally (it's a free hosting service). So if I load the file and search for say "expression" and abort the load if I find it, I should be ok?
fudgey
Thanks Flea... I forgot about evil IE and the expression tag.
snicker
I'm not certain. I believe that there is a way for Javascript to be used outside the `expression()` call, such as date objects, but I've not seen an example recently. I'll take a look and see what I can find.Do you have database access?
The Wicked Flea
@snicker, no problem. I hate how IE has forced the others into supporting it.
The Wicked Flea
Nope the site is pretty basic, no database is being used. But I am caching data on the site in either an XML or HTML file (but only for 10 minutes).
fudgey
Are there any sessions or cookies to worry about? If not, then go ahead with the stylesheet. (Just bear in mind that it'd be easy to add in a tracking image.)
The Wicked Flea
Not using sessions or cookies... and the user sets the CSS url on their own site in an iframe.
fudgey
A: 

It depends upon how it is used. If it is possible for one user to see your site using someone else's stylesheet, then you're setting yourself up for abuse.

BryanH
No the user themselves use this information in an iframe, so I don't think there is a risk of something like this.
fudgey
+2  A: 

It appears that XSS and presumably clickjacking can be done through CSS. You should certainly be careful that the CSS URL cannot be set with a CSRF attack.

If your server is making the request to load the original CSS file, then you mgiht want to be concerned about that outgoing (or perhaps local) connection. If the client is doing it, then you might want to be concerned about leaking information in URL (fortunately sessions by URL rewriting is no longer popular).

Tom Hawtin - tackline
Sorry, like I said I'm fairly new to php. What kind of risk does this have? Potentially disrupting the information and/or wiping my server?
fudgey
For the server making the request? In that case the CSS URL could point to an internal web server, a local file, a device, etc.
Tom Hawtin - tackline
+2  A: 

Yes.

It is a bad idea.

What others have said is exactly correct but one very important additional point is that if ANYONE besides the user updating the css EVER views their css then that user can execute any javascript they want in the context of the user viewing their page. The worst case scenario here being user updates their own page with malicious xss, you view their page (logged in as admin), user steals your password and logs in as you and takes over the site.

Depending on what other security issues you have in your site stored cross-site scripting such as this could lead to an xss worm like the myspace samy worm.

Here is a decent link about some variations on css-based xss, http://www.thespanner.co.uk/2007/11/26/ultimate-xss-css-injection/

Collin
Wow that is scary, but I think I'm ok as the page with the custom CSS is displayed inside an iframe on the users site only. And if I did plan on viewing their page I wouldn't be logged in as an admin (it's a different site anyway) and I only access my site via FTP.
fudgey
That sounds better! As long as by "the users own site" that means a page only the user itself can see and no one else can ever see. Because another attack vector could be the user creates thier own site, adds some evil css and then emails a link to that page to every other user on the site, any user who is logged in will have their cookie information taken. I don't fully understand the construction of the site though so the above scenario might not apply.
Collin
@fudgey: You should also *never ever* render their CSS yourself, no matter who you're logged in as. Not even for debug purposes, however tempting it might be. Well, unless you're logged in from a security lab setup of some sort, but in that case you'll already know way more than I do. :)
Ilari Kajaste