1. You register foo.com as your redirect with FB. Your oauth endpoint is actually foo.com/fbauth, but Facebook is OK with just the domain.
2. Somewhere else on your site, you allow open redirects, like maybe a user can create a link that you proxy with a redirect for click-tracking purposes, like foo.com/links?url=evil.com
3. An attacker makes an oauth query to Facebook with the redirect URL hacked so that it points at foo.com/links?url=evil.com
4. FB dutifully sends your user to the hacked URL, which redirects to evil.com with all of its hashy stuff in place.
5. Javascript on evil.com reads the hash and uploads it
It's not clear--and I'm too lazy to test--whether FB will restrict the forward to foo.com/fbauth if you're explicit about it when configuring your app. But certainly the wording on the developer console just asks for your site URL, and even though I'm pretty familiar with oauth, I have never bothered to do more than that. Google, on the other hand, forces you to.
Thanks for explanation.
May I ask how the attacker can make "an oauth query to Facebook with the redirect URL hacked so that it points at foo.com/links?url=evil.com"? Are you saying that attacker somehow convinces user to visit maliciously created Facebook authentication URL?
Right, I worded that poorly. You need some other vulnerability for the attacker to pull this trick off. But, like homokov says, there are a lot of possibilities for that. Obviously, such a vulnerability is bad on its own and the site owner should prevent it, but FB should be better about mitigating it from their end.
1. You register foo.com as your redirect with FB. Your oauth endpoint is actually foo.com/fbauth, but Facebook is OK with just the domain.
2. Somewhere else on your site, you allow open redirects, like maybe a user can create a link that you proxy with a redirect for click-tracking purposes, like foo.com/links?url=evil.com
3. An attacker makes an oauth query to Facebook with the redirect URL hacked so that it points at foo.com/links?url=evil.com
4. FB dutifully sends your user to the hacked URL, which redirects to evil.com with all of its hashy stuff in place.
5. Javascript on evil.com reads the hash and uploads it
It's not clear--and I'm too lazy to test--whether FB will restrict the forward to foo.com/fbauth if you're explicit about it when configuring your app. But certainly the wording on the developer console just asks for your site URL, and even though I'm pretty familiar with oauth, I have never bothered to do more than that. Google, on the other hand, forces you to.