I've been using a separate browser for FB for quite a while now.
Is what you're doing more secure than that?
IMO mass assignment was discovered not last year. 2006 maybe?
Dude's been on a pretty solid streak for the past year.
this is completely different thing. I don't read your visited links, i read your current URL in window. and they fixed it, I recall.
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.)
Also, I had to allow popups.
sorry again for buggy PoC!
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.
blocked is ok, just wait.
i said 'detect'. you can check against predefined 10-50 list of friends
Not that it's hard to get people to click links, but am I missing what's so "nifty" about this vuln?
First hit when you Google for [facebook report vulnerability]
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.
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:
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.
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.
for example Single sign on and OAuth2 redirect you to path?code=.. and it's also guessable
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.
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
So we change the standard. And?