*What* css security issues?

[branchandroot]

Okay, I am annoyed. I have been unable to find any security issues associated with user-entered or user-uploaded CSS except in cases where a url is permitted as a value. Presumably setting one's loading form to refuse any document with http in it anywhere, or just strip the http string, will fix this.

So WHY is the AO3 skin dialogue so freaking limited?! *yanks own hair* This is supposedly for security reasons, but I fail to see what they could possibly be as long as http strings are axed.

Especially the :before. I could see it being a vandalism concern, but that just means that the reviewer for public skins may want to do a quick find for any "before"s or "after"s. But a security issue? And for pity's sake what's the problem with text-transform? Is there a security issue with me capitalizing things?!

This brief rant brought to you by the number of CSS variables which do not seem to be whitelisted for even private AO3 skins. And the increasing suspicion that both the explanation and the error message script were poorly thought out, totally aside from the obvious bugs in the allow/disallow script.

All I want is some freaking metadata labels! This platform has distinguished itself as the second, only after Wordpress, to receive an "argh" tag of its very own.

Comments

[branchandroot]

*growls* You may be assured, I've sent feedback on this one. About three messages worth by now, one feedback proper and two bug reports, because wow is the allow/disallow script messed up. Keeps saying I can't have stuff like a vertical-align set to baseline or basic borders or stuff like that. *shakes head*

Do people think that :before will let anyone put in actual html or something like that? Or maybe it's just knee-jerk "injection, omg, kill it with fire!". *snorts*

[synecdochic]

Pure CSS can be pretty dangerous all on its own, and is the most common vector for XSS attacks, which in turn were something like 90% of vulnerabilities discovered last year. It's definitely a security issue: if you have total control over the CSS you can add, you can get at the user's cookies and force their browser to run whatever you want it to.

(Which is not to say that your frustrations about the whitelist are not warranted, etc! I'm sure there are some things they forgot to whitelist, and that's why LJ/DW uses blacklist and not whitelist. But still. It's not as harmless as people think.)

[branchandroot]

*reads the examples*

That last one is very confusing, given the author is using CSS for Cross Site Scripting rather than Cascading Style Sheet. I can see why XSS is more common.

At any rate, aside from adding any string including &x to the "strip this out" list, along with anything http, none of this would be applicable to user-loaded styles, at least on AO3. They're already escaped and run through a rendering engine to boot.

I'm not suggesting throwing away the blacklist, but what's in place there now is getting really absurd, and way beyond anything that would address the security examples you've mentioned.

[synecdochic]

Ah, got it -- I'm not at all familiar with AO3 stuff, since I don't have an account there!

[branchandroot]

It's actually shaping up pretty well as a platform. In general I'm very pleased with it. *wry* It's just... well, me and design, you know. I waited a few months after the "load your own skin" was released, hoping that would get the bugs out, but, um, no it kind of looks like the beta tester is gonna be me. Which I'm usually okay with, just, this has some doozies of bugs in there still. I'm trying not to froth like this in my actual reports and feedback, but I /really/ had to froth somewhere!

[synecdochic]

Oh, I totally grok the needing to froth. :)

[branchandroot]

Re: edit,

See, this is why I love DW.

And I have actually figured out how to make the commas in the AO3 tag list transparent while keeping my :before inserted tag labels visible, so I suddenly feel far more mellow.