Page MenuHomePhabricator

Mitigate OAuth session theft
Closed, ResolvedPublic


See discussion here:

Specific items are:

  • Update the configuration for this install.
  • Update the configuration instructions for all installs.
  • Check the viability of doing an API test for configuration.
  • Render all forms with an action attribute.
  • Whitelist access_token as a GET parameter globally.

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Security.
epriestley added subscribers: epriestley, arice.

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:

Screen_Shot_2014-03-12_at_7.46.26_AM.png (609×730 px, 60 KB)

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:

Screen_Shot_2014-03-13_at_8.03.51_AM.png (58×746 px, 10 KB)

Okay, I think I can't read these fields over the API:

  • Valid OAuth redirect URIs
  • Client OAuth Login On/Off
  • Embedded browser OAuth Login On/Off

...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 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 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:

  • Unable to remove authorized domain from "App Domains"
  • OAuth security settings (whitelist, client toggle, embedded toggle) should be configurable from the API
  • Client / Embedded Browser OAuth settings should be documented (individually or linked to
  • The link above needs to be updated to match the recent devsite redesign
  • Wishlist: Consolidation of all settings that impact OAuth attack surface
epriestley claimed this task.

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.