Page MenuHomePhabricator

Harden Phurl against anchor reattachment
Closed, WontfixPublic

Description

See D8517. I don't immediately have a clean way to defuse this, although our global intercept of the code parameter is likely sufficient to prevent it, as is disabling "Client OAuth Login" in, e.g., the Facebook configuration. The three obvious options are:

  • Add an empty anchor if the URL doesn't have one (but this is messy from a user perspective).
  • Do the redirect on the client side in Javascript (but this is icky).
  • Don't do anything and rely on code / configuration protections (or do something like just document this stuff).

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added projects: Phurl, Security.
epriestley added subscribers: epriestley, lpriestley.

(This is just a note for me to make sure I don't forget about it, I'll follow up here before we unprototype.)

I ultimately don't think there's any really reasonable way we can fix this that doesn't have a cost and complexity far greater than the benefit.

To summarize the attack, if you visit http://some.site.com/#anchor and it returns a 3xx with a Location header, some browsers will preserve the anchor upon redirecting.

For example, if you follow this link, adjusting the anchor to whatever you want:

http://bit.ly/1RDEnNn#quack

...you'll end up back on this task, but the anchor will be preserved in Chrome and Firefox.

To turn this into an attack, you use it in a situation where Facebook puts OAuth secrets in the anchor. So the anchor reads #secret=abcdef, you get Facebook to send the user to https://phabricator.example.com/u/123#secret=abcdef (this is somewhat involved), and that redirects them to evil.com with the anchor and secret intact, where JS reads it on the client side.

The attack is specific to OAuth servers which pass credentials in anchors, which I believe may only be Facebook's. Our OAuth instructions for configuring Facebook already advise users to whitelist exactly one redirect URI, which effectively closes this vulnerability. Modern OAuth providers should generally be encouraging this (we require it in our implementation).

The modern Facebook developer console doesn't go as far as requiring a redirect URI whitelist, but does encourage users to provide one:

Screen Shot 2016-03-27 at 8.58.50 AM.png (77×807 px, 13 KB)

So, to be vulnerable, users need to:

  1. configure Facebook as an OAuth provider (or possibly another similar OAuth provider);
  2. ignore our instructions to whitelist; and
  3. ignore Facebook's instructions to whitelist; and
  4. allow the attacker to create a Phurl; and
  5. follow a link given to them by the attacker; and
  6. use an anchor-reattaching browser (Chrome and Firefox reattach; Safari currently does not).

This chain of events isn't impossible, but I believe they present a reasonable degree of difficulty and that we don't need to take extraordinary steps to prevent this.

If we did want to try to mitigate this, a better test might be to make an effort to verify that the Facebook OAuth application is properly configured, since that's the root issue and improper configuration exposes users to a broader class of vulnerabilities (although this one is the most substantive).

I'll also open a followup for possibly adding trust settings in some future version of Nuance (e.g., maybe you want to follow links by epriestley without confirmation but prompt before following links from users who you don't trust as much).