4 ms·

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.

• peterbraden 14y ago
  not true - it's a timing attack right? There's nothing in the spec that says they can't spoof a timing delay?
  • blakel 14y ago
    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.
    • homakov 14y ago
      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
  • homakov 14y ago
    it would look very ugly...
• JSadowski 14y ago
  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.
  • blakel 14y ago
    That probably breaks links though.
    • grey-area 14y ago
      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 http://facebook.com/profile.php - private profile, no redirect http://facebook.com/some.user.name 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 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.
      • homakov 14y ago
        FB is only showcase for example Single sign on and OAuth2 redirect you to path?code=.. and it's also guessable
      • nadaviv 14y ago
        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.
• quotemstr 14y ago
  > Because it's standard So we change the standard. And?
  • homakov 14y ago
    can we? It was marked Wontfix in chrome