Support for @import and @font-face

[alisx]

Title:
Support for @import and @font-face

Area:
styles

Summary:
Update the CSS cleaner to support modern CSS, including the @import and @font-face directives.

Description:
The current CSS cleaner is overly-restrictive in what directives it supports, which makes designing modern layouts unnecessarily difficult.

In particular, the @import and @font-face directives should be supported (at the current time they are stripped out). The former allows for clarity and organisation of code for designers (as well as the use of well-known frameworks and reset styles), while the latter is becoming a staple of "Web 2.0" design.

While care still needs to be taken to protect against malicious XSS attacks, the @import and @font-face directives in-and-of themselves wouldn't seem to be any more dangerous to users than, for example, background-url (which can also be used to import foreign data).

Poll #2513 Support for @import and @font-face

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
11 (34.4%)

Should be implemented with changes. (please comment)
1 (3.1%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
20 (62.5%)

(Other: please comment)
0 (0.0%)

Comments

[foxfirefey]

I think font-face is easily doable, and there's a post about best practices here: http://layoutmakers.dreamwidth.org/5590.html

We'll have to make some changes in where the CSS comes up in S2, I think, for the best results.

@import is a lot harder, I think, because the imported CSS can't be directly imported, but has to be redirected through the CSS cleaner. I think it might be possible to do, though, with a bit of work.

[alisx]

What's the justification for the CSS cleaner, really?

I mean, beyond the obvious (ensuring CSS files are, in fact, CSS files); why does it need to vet every line and every directive in every file? How prevalent/severe are CSSXSS attacks? Do other sites that allow foreign CSS clean their files as rigorously? With the current cleaner can you, for instance, load malicious resources (including things like renamed scripts) using already-accepted url() directives?

Semi-rhetorical, I guess; I know the exploits, but the way the cleaner currently functions seems like overkill, especially considering all the other ways I could launch an XSS attack via a journal if I really wanted to.

... and it also just really, really drives me nuts (for seemingly not a great deal of payoff). 6^^

[mark]

If you can find a way to launch an XSS attack on Dreamwidth, please email me -- I want to talk to you.

As to the CSS cleaner, I was there when it was written. We were having some serious issues with browsers (particularly IE6 with its inability to properly handle JS in many cases) getting repeatedly destroyed by various things that you could do in CSS.

User safety is paramount. I'd rather have a site that isn't super snazzy and yet protect people's privacy and their computers than have one that's got all the latest bells and whistles and have to deal with people getting exploited every day.

[alisx]

If you can find a way to launch an XSS attack on Dreamwidth, please email me

There are a couple of vectors I can think of off the top of my head, but I'm not really in the habit of trying to break DW so I haven't explored them. Besides, I'd be highly surprised if they worked; I'm an analyst, I do the questions and the assessments, but need input from clever hackers for the wetwork. :P

If I really had a grudge, the main thing I'd be running is a phishing attack against the reply form in the HTML comment notification email, though. It's kinda obvious, but a good soft entry-point. (Er, not that I would, I should point out, but that form's always annoyed me.)

We were having some serious issues with browsers (particularly IE6 with its inability to properly handle JS in many cases) getting repeatedly destroyed by various things that you could do in CSS.

Is that still a real issue, though? I'd imagine things have moved a bit since then. And by "destroyed" are you talking "pages unreadable" or "user's computer is compromised"?

I'm honestly just really curious now. :P

User safety is paramount.

Sure, but security and usability are different points of the triangle; and I'm not a fan of compromising the latter to "protect" against exploits that can't be actualised in the Really Real World.

That's just me and my professional ideology talking, though. And I'm used to having the unpopular opinion on this one. 6^^

[denise]

Trust me, the exploits we're defending against have been repeatedly actualized in the Really Real World on LJ, and there are plenty of people who are still trying them against us.

[exor674]

@import would have to go through the cleaner, as described above. Will also have to look into @font-face, make sure there are no known exploits with bad fonts/not fonts/other URIs.

Barring that, I'm +1

[mark]

Most of the exploits ended up with compromised cookies. This can lead to someone impersonating you and deleting your content, pretending to be you, or just invasion of your privacy when they read your protected content.

I'm not a fan of compromising usability either, and sometimes we'll make concessions in that direction if the needs are dire. But when it comes down to it, I still think I'd rather have a safe site.

[alisx]

So, like, an exploit of IE's lax @import DOM restrictions?

But... wait a sec, you can do that on anything that uses url() (e.g. @font-face and background)... which of course gets us back to the cleaner and its high-byte stripping, again.

Hm.

Okay, so maybe not @import. I still want @font-face, though. :P

[foxfirefey]

@import is not technically impossible! I think we could modify the cleaner to accommodate it by replacing the url with a URL that goes through the cleaner. It might be a little performance hit, but I think it could work.