| epriestley | |
| Mar 12 2014, 2:22 PM |
| F127908: Screen_Shot_2014-03-13_at_8.03.51_AM.png | |
| Mar 13 2014, 3:04 PM |
| F127090: Screen_Shot_2014-03-12_at_7.46.26_AM.png | |
| Mar 12 2014, 2:47 PM |
See discussion here:
https://secure.phabricator.com/D8481
Specific items are:
I updated the "Site URL" to include the path, but am still getting redirected off that path when clicking, e.g.:
Presumably this is a cache issue, but I want to wait for that to start working before updating the documentation in case I did something wrong. Here's what the panel looks like in case I'm doing something goofy:
More than 24 hours later I'm still getting redirects anywhere on the domain from Facebook, so I think I either did something wrong or this isn't working for us for some reason. I'll take another look at your replies in D8481, but at least as a normal app administrator I can't figure out what I'm doing wrong by poking through the tabs.
It would be vaguely desirable if we could disable the token response type entirely. We never use client-side workflows, and because of hash reattachment after 302 in most browsers it's dramatically more dangerous for us than GET parameters. Notably, goldshlager found another equivalent attack using the 302s from our OAuth server implementation, and I don't have a good general mechanism for shaking off data in the anchor without the mess of doing the redirect on the client with JS or meta-refresh.
Ah, okay, it was my mistake -- I needed to separately configure "Valid OAuth Redirect URIs".
And I can wipe out the token flow ("Client OAuth Login").
It would be helpful if this panel was linked to context, I have almost no idea what these things are:
Okay, I think I can't read these fields over the API:
...but the most-correct configuration should have particular settings for each of them (as per new instructions in D8518).
I am also unable to remove the "App Domains" setting for this application (as per https://secure.phabricator.com/D8481#6). When I delete the token and hit "Save Changes", the page says "Saved" but the token reappears a moment later.
Whatever bug is preventing the removal of phabricator.com from App Domains is at fault here. It's presence authorizes the entirety of the domain for the OAuth flows (unless overridden by "Valid OAuth redirect URIs"). We (Facebook) need to do a much better job of guiding developers through reducing OAuth attack surface - the redesigned dev site is noticeably worse in this context.
Several issues here I'll file tasks for:
I think there's nothing actionable remaining here. Both our and Facebook's modern instructions encourage users to whitelist redirect URIs.
T9744 has a more up-to-date discussion of the attack against modern versions. There, I've chosen to permit attackers to attempt this attack via Phurl if other conditions are met, because the threat seems smaller than the cost to mitigate it.