Are you taking away our freedoms for your security?

December 12, 2005 11:40 AM

Ok, in this comment by #1, it is revealed that user pages have been considerably further locked down. I wonder, is all that extra security still in place? [more inside]
posted by mystyk to MetaFilter-Related at 11:40 AM (23 comments total)

In that comment it was explicitly noted that custom stylesheets are no longer permitted. That's great for those who don't use them, but a number (like myself) still do. I can see that as of this writing pages haven't been scrubbed, and I'm guessing you probably don't care to since none of them are causing problems.

What about people who want to keep the style but update a few other factors? I wanted to set the image to a flickr spot so as not to tax my personal server. I want to retain the custom flow, but be able to update the other stats. I was all set to make a major content revision in the next week. Is the ability for both lost the moment I hit submit?
posted by mystyk at 11:40 AM on December 12, 2005

"...is all that extra security still in place?"

For clarity, I'm really referring to the user-page stuff, and especially custom stylesheets. I don't mind the captcha.
posted by mystyk at 11:42 AM on December 12, 2005

Yes, the security is in place. If you save your preferences, your custom page will be lost. Sorry, but I can't let people go crazy with style blocks anymore, thanks to all sorts of cross-site scripting hacks out there.
posted by mathowie (staff) at 11:58 AM on December 12, 2005

What about validating the CSS? If it passes then it should be ok. You can submit via GET but not sure how to automate checking the result.
posted by Firas at 12:29 PM on December 12, 2005

I never checked out how the CSS was done though so maybe it's not as straightforward as a textbox of CSS added to the document head.
posted by Firas at 12:32 PM on December 12, 2005

Can someone explain this in language a CSS anti-wizard would understand? I've read the relevant threads, but I don't really understand how custom stylesheets relate to the P_G/al'hazred -> CAPTCHA story.
posted by goodnewsfortheinsane at 12:41 PM on December 12, 2005

I wanted to set the image to a flickr spot so as not to tax my personal server. I want to retain the custom flow, but be able to update the other stats.

Question: given the list of requested ponies and other possible enhancements to the site (not to mention the monitoring work), how much of a priority are the following?

* Monitor security problems reported in various forums to identify those that might impact the fancy things that a few users do with their profile pages.

* Update and modify site software in response to identified security threats and reported problems so that members can (continue to) do fancy things with their profile pages while not threatening the security or stability of the site.
posted by WestCoaster at 12:42 PM on December 12, 2005

goodnews, I'll take a shot. It's possible to inject executable code into database queries by exploiting weaknesses in how various browers parse the Document Object (better known as a "web page"). Matt was letting people call remote stylesheets and javascripts on their user pages; it let us do cool thinks like load our own blogs into an embedded frame or radically redraw the user page, with new colors and borders and all kinds of cool stuff.

CSS just happens to be one medium whereby injection (or other exploits) could happen. The only thing relevant about it is that we don't get to play with pretty things anymore.

Well, it was a dangerous kind of pony, it turns out. So now that pony has been taken away.

It was really the right thing to do. Sad to see it go (though my own stylesheet was no great shakes), but we're all safer for it being gone.
posted by lodurr at 12:56 PM on December 12, 2005

goodnewsfortheinsane, they don't relate completely, aside from the fact I looked at every form submission on the site, looking for obvious security holes, and the custom user pages was a huge gaping hole (that no one had exploited to date, but they could have).

Basically, it was fairly easy to put some script on your userpage that read a user's cookie and sent it to you. It was possible to suck down the password of anyone visiting your user page, in the past. I decided to filter all user page submitted copy against the controls I use for comments, which filters out scripts and iframes and style info, since those are prone to exploits.
posted by mathowie (staff) at 12:58 PM on December 12, 2005

Has PG been banned?
posted by xmutex at 1:52 PM on December 12, 2005

Ah, that makes sense. Thanks, Matt.
posted by goodnewsfortheinsane at 1:55 PM on December 12, 2005

It's not that all CSS allows exploits, but that because of the difficulty in distinguishing malicious use from appropriate it's easier to throw it all out. Until it's possible to distinguish good from bad it's a good intermediate fix to keep users safe.

Valid CSS can be still be exploitable. Not in just the usual CSSXSS, but in simpler ways such as absolute positioned hyperlinks over site navigation that link to phishing sites.

The main problem is parsing CSS syntax into something you can then easily whitelist, then convert that back into inline style. But there's little point solving this without fixing the wider issue of parsing HTML and CSS, and then what makes sense is to convert inline style to XML attributes, and whitelist them just like any HTML.

Regex-based parsers don't work (or at least they aren't granular enough to distinguish good from bad). I've got code if you'd like Matt but I guess it's no use to you in CFMX, so here's the process:

1. Attach html/body tags to the submission, and run it through HTML tidy. This fixes all the variations of unquoted or single-quoted attributes, malformed elements, so you've now got a far more uniform bit of XML to parse.
2. On the resulting string regex replace style="" and <style>. Don't split the string on ; or }, because those can be valid characters for "content:" and some aural properties. Keep lefting the string to find boundaries and turn each property into an XML attribute.
3. Run the XML through an XML parser that whitelists all the valid elements and attributes (eg, XSLT).
4. Collapse the remaining CSS attribuytes into inline style (eg, XSLT).
5. (Store/cache the result)

That's the web condom, allowing you to get close and rub up against it without catching something.
posted by holloway at 2:23 PM on December 12, 2005

Does this mean no more pretty sites like taz's, or just that taz'z site would become ordinary blue if she altered it?
posted by Cranberry at 2:38 PM on December 12, 2005

of course you all know that should be taz's
posted by Cranberry at 2:39 PM on December 12, 2005

Essentially, yes. Taz, jessamyn, myself, etc. do those effects primarily (but not exclusively) through css. That method is now disabled, much to my dismay. Matt's making the site safer at the price of a pretty useful (but not necessary for the site to run) pony. From what I gathered, all pages with non-malicious code are considered grandfathered in, and no other user will be able to do so from now on, plus the moment one of us wants to update content we lose it too.

"Those who sacrifice liberty for the sake of security deserve neither liberty nor security." - Benjamin Franklin
posted by mystyk at 2:58 PM on December 12, 2005

If you're working on a parser matt I'm on irc.ieattapes.com some of the time. /msg me if you want.
posted by holloway at 3:16 PM on December 12, 2005

Thanks, mystyk. Guess it is another case of the innocent suffering for a bunch of childish cretins the guilty
posted by Cranberry at 3:42 PM on December 12, 2005

oh , i thought the abl guy was dhoyt...
posted by sgt.serenity at 3:43 PM on December 12, 2005

Hilarious sgt.! Perhaps there are only a half dozen real people and the other 30k are sock puppets.
posted by Cranberry at 3:50 PM on December 12, 2005

which filters out scripts and iframes and style info

This means my embedded comment thread on my user page will go away the next time I edit it. :( iframe...

Of course, if MetaFilter had a place for posting comemnts on each profile page... that would be pretty cool.
posted by kindall at 4:09 PM on December 12, 2005

That way we could comment on other user pages and tell them to use Phpilfer.
posted by holloway at 4:11 PM on December 12, 2005

mathowie : "Basically, it was fairly easy to put some script on your userpage that read a user's cookie and sent it to you."

mystyk, you bastard. Every single one of these "cool user pages" MeTas, I end up re-visiting your user page. And every single time, you collect my password.

I still like your user page, and envy it.

Note: mystyk is not doing anything wrong. I just like to overreact, is all. Disregard the earlier statements.
posted by graventy at 12:51 PM on December 13, 2005

How long till the pitchforks and forced outing of mystyk? I've got 20 min / 6 comments in the pool!
posted by phearlez at 12:58 PM on December 13, 2005