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:
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.
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.
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.
It only shows what FB pages have been visited - If I go to /egor.homakov and then type that in for my match string, it says that's my username.
How is this different from reading link colors / setting a:visited behaviors to see where you've been? (I don't remember if browsers have fixed that "bug" or not, it's an old exploit.)
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 !
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?
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
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.
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?
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:
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:
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.
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.
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.
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.
