I Can Detect Your Facebook Username, Using W3C Standard | Hacker News Reader

I Can Detect Your Facebook Username, Using W3C Standard

homakov.blogspot.com

96 pointshomakov57 comments

It didn't work but I know why: I use a different browser for Facebook—not because of these hacks but because Facebook itself is more invasive than any of these tricks. I don't want to accidentally connect what I browser with Facebook. I have a separate browser icon that launches:

  google-chrome --user-data-dir=/home/myaccount/.config/facebook-chrome

And that launches directly to Facebook. I keep Facebook stuff nicely contained in that browser. I mostly just follow links out of Facebook. The real Chrome never even knows that I'm on Facebook.

you are paranoid a bit :) do you have browser for each site?

No, he has a browser for Facebook.

I also hope you use rule-based blocking on any third party crap Facebook might be serving - i.e. tracking - you on different websites by matching your IP.

I use an Incognito window for Facebook and login each time I want to see something.

Is what you're doing more secure than that?

I did that at some point but this is more convenient. My Facebook browser has me logged in all the time, I just need to launch it to check Facebook.

I don't try to prevent Facebook from figuring out who I am or what I do. They should have a huge amount of info about me, but their ads are still entirely irrelevant.

It's not the ads. It's the "I'm already logged into some random app and one click away from accidentally doing something I don't want to do".

I've been using a separate browser for FB for quite a while now.

Good idea, more simply a dedicated google chrome profile can be used..

Isn't this the same guy who discovered the mass assignment bug in Rails last year?

> who discovered the mass assignment bug

IMO mass assignment was discovered not last year. 2006 maybe?

Yep.

Dude's been on a pretty solid streak for the past year.

Cool story, followed link, tried example, it doesn't work at all. Either Facebook fixed it, or it was crap.

i had a typo in PoC, now it clearly works

Isn't it time browser implement a "safe" mode: - Sharing cookies between tabs? Nope, unless you personally opened it another tab, and expires as soon as you type in a new url. - Access or url on a different domain ... maybe, but certainly not to localhost. - Font access ? No - Plugin listing ? No - Whatever the hell I don't know about: No. Then either allow the user to whitelist the site, and/or allow certain parts. Would it be easy for the user? No. Would we weed out a lot of issues? At least a few !

That would break way too many things to be acceptable. Web technologies are stupidly backwards compatible.

I know ... but if you are going to be backwards compatible with security flaws/designs ... cheese ... then it's never ever going to get fixed, and I'll stop bothering making web-apps: no security future!

But can't you also find someone's username by hiding the facepile plugin from the user, waiting for it to load, then pulling the username once it's loaded?

Not "pulling", detecting. Vuln is not severe but it is still fun!

This doesn't actually work. After allowing the popup, it just confirmed whatever username I put into the text box.

Same for me, but I also note that whatever I put in the dialog, I get redirected to my actual Facebook page.

Also, I had to allow popups.

https://www.facebook.com/profile.php always links to your actual Facebook page, so being redirected there doesn't mean the PoC is working.

I know I was implying it wasn't.

There was a typo in my code! Sorry, now updating

you can check only one username at time now. there was some caching / navigation bug which i don't have time to polish :( also default timeout = 9000 now! Please test http://homakov.github.com/fbdetect.html

sorry again for buggy PoC!

Okay, maybe I was stupid but I couldn't find the link to the demo in the article. Author posted it somewhere here in the comments: http://homakov.github.com/fbdetect.html

So all this does is to check if my username matches with some preexisting username. Its no way you can detect my username if you don't already know it. Also even after I gave the demo my username, chrome simply blocked a popup and the whole thing failed...

Either I don't get it or this is a lot less impressive than the title suggests.

> chrome simply blocked a popup

blocked is ok, just wait.

i said 'detect'. you can check against predefined 10-50 list of friends

From what I gather, it would be useful for targeted attacks - bruteforce wouldn't really be viable if your handle takes 50 years to generate in javascript?

Not that it's hard to get people to click links, but am I missing what's so "nifty" about this vuln?

Didn't work for me although I was logged in to facebook. Chrome 25.0.1364.99

Same, chrome 25.0.1364.97.

this happens when facebook is "down" or when u set bad timeout /https. Can you trace urls you get ? Https enforcement?

guys, my bad - typo :(

WFM now =)

LOL, i entered my handle and it says I am not my handle!

www.facebook.com/whitehat/report/

First hit when you Google for [facebook report vulnerability]

1) it's minor but still fun 2) facebook is only showcase, it's basically UNFIXABLE

How much does it matter if you know my username? As long as you don't know my password right?

FWIW, it's still working.

it is buggy, but conception is working. the thing is THERE IS NO WAY TO FIX IT. Because it's standard. and this is the fun part.

not true - it's a timing attack right? There's nothing in the spec that says they can't spoof a timing delay?

It's not a timing attack.

The behavior of the browser, after appending an '#' to location.href, is different depending on the value of the current URL.

The state of the browser after making such a change gives you information about what the current URL was before making the change.

The information it gives you is whether or not you only appended '#.* ' to the current URL.

Normally, this information is only available in this context if the current URL follows the code origin policies of the currently executing code. In most browsers, this means you can only look at current URLs if they are in the same domain as the executing code.

The article shows code that exploits this to try to guess your Facebook username.

This is interesting 1) because it allows for brute force attacks to gain potentially sensitive information and 2) this may cause new discoveries that could make this more efficient or that expand what is possible and 3) because this behavior is as designed.

yes i fully agree with your points but it's still two vulns

1) detecting URL by assigning hash + onload (iframe)

2) detecting URL by assigning hash + timing of history (window)

i just made it work for both frame/window this way

it would look very ugly...

No way to fix it? Not that they should, but Facebook could just stop redirecting www.facebook.com/profile.php to www.facebook.com/<username>

By making that change (and having no other way to hit a page that redirects to my user page), there is no URL for the attacker to check against.

That probably breaks links though.

Who needs to link to the current user's profile page without knowing it? Only FB should have to do that and they know the profile page url. Other people should be linking to the profile page directly only if they know it, not based on which user is viewing. They should really have two profile URLs:

http://facebook.com/profile.php - private profile, no redirect

http://facebook.com/some.user.name - public profile (profile.php?id=123 could redirect here given an id so as not to break old links)

To fix this FB could stop doing this redirect entirely as it leaks information about the current user's session, and should not be necessary. I'm sure it'll break someone's links, somewhere, but it was a bad idea to begin with, and related is this old trick which let's you view a very popular profile:

http://facebook.com/profile.php?=112398345098345

All that should be required is a public profile url which can be shared (if you wish) or not, and a private profile url, and the url of the private profile should be generic and not redirected, so that it doesn't leak info in this way, and because it's not the same as a public profile anyway.

FB is only showcase

for example Single sign on and OAuth2 redirect you to path?code=.. and it's also guessable

The problem with that is that different people viewing the same URL (/profile.php) gets a different resource. What happens if someone gives a link to his profile.php over IM or something, expecting it to show his own profile? The URL the user is shown in the address bar should represent the current resource being viewed.

A better solution could be to replace links to profile.php with direct links to the real profile URL, and just kill that profile.php redirection.

In the same way that different people viewing:

http://facebook.com/

see a different resource? For a web app like FB I don't think this avoidable. All data served is dependent on who you are when you are logged in.

For another example of how to handle this better, see twitter:

twitter.com - the user's feed, content differs for each user

twitter.com/username - the user's public url, for sharing, a proper URI which everyone can use

twitter.com/settings/profile - the user's private profile, content differs for each user

I agree they shouldn't need that redirection with no id supplied and I suspect it's just a legacy of the original way of showing profiles (profile.php?id=n), they could just redirect it to root instead (shows the same as profile.php it seems) to avoid leaking state.

they probably need this functionality..

> Because it's standard

So we change the standard. And?

can we? It was marked Wontfix in chrome

very nice

Reply on news.ycombinator.com