3 ms·

> How could an attacker manipulate a URL to redirect somewhere else? A site begins writing software to OAuth with Facebook. They start by filling out a form o

> How could an attacker manipulate a URL to redirect somewhere else? A site begins writing software to OAuth with Facebook. They start by filling out a form on Facebook with app name and the callback URL to their site. They then write a handler on their site for dealing with the callback URL they expect to receive from Facebook after the user approves the connection with their app. However, the week before the company did OAuth integration, there was a ticket opened for 'redirect user to correct page after login' which was implemented with a '?next=http://urlofyourchosing.com/' http://urlofyourchosing.com/' decorator handler written by the Swedish intern. The redirect parameter isn't going to be compared by Facebook. Only the base URL is going to be checked to ensure it matches. Once Oauth integration is complete and tested, the site launches. They get on the front page of HN, Reddit and Mashable and sign up about 100K users in a few weeks. In the meantime, a bad agent discovers the flaw in their login flow and tests the behavior and discovers the ?next redirect 'venerability'. They know the site uses Facebook, so they craft a URL to do OAuth with Facebook, then redirect the user to the attacking site by using the ?next parameter located in the third party's website code. They then use the current bad actor method of propagating their evil URLs and .... profit? Impact: Any action by the user allowing access to data will, in theory, allow the attacker to view the information they gave the site access to and, possibly, more information than the user originally approved for the site if they accidently chose another security scope. It should be noted that all access by the user to both Facebook and the attacked website will be logged by their respective servers. I implemented an OAuth2 workflow with Github to an AppEngine project last year, so I'm at least passingly familiar with what goes on under the hood with the flows. Still, I could be missing something here. I might try to hack up a working example to test my theory.

gcb0 13y ago
This assumes the url that process the ?next request pass the info in a Crossdomain way... Ie get vars or post. Everyone does cookies or backend storage. unless you can compromise the target dns, this is impossible to exploit except for very lousy sites... But if they are bad to this point, you probably already have a local shell access
- tomvangoethem 13y ago
  When you are redirected from Facebook - either after clicking "Accept" or in an implicit flow - to the page with the next parameter, and that page redirects to attacker.com, then attacker.com will have access to the referer header†, which contains the access token. Using this access token, an attacker could extract the sensitive information from the victim's Facebook account. † there are a few exception when referer header isn't shown, e.g. HTTPS->HTTP redirect, but an attacker could make sure that the referer header would be sent for the majority of victims
  - gcb0 13y ago
    Always assumed the response was via post... It's silly to use get/url for that. Any ad or external library on the page can already see that then.. Everyone logs referer headers. Even using custom fonts directly from Google is already advertising your tokens...
EGreg 13y ago
I read all the above and I still don't see how the attacker would "gain access" to the user's info on the platform. How do they get the bearer token? ?next=URL is usually implemented to redirect to the URL, and won't propagate the bearer token off the app to the attacker's site. What Am I missing?
- deleted 13y ago
  [deleted]
- kordless 13y ago
  Given you implemented it correctly, I would agree with you. A bad implementation would allow for preservation of the URL's parameters ala urllib.urlencode(self.request.params) or similar, which would contain the token.

gcb0 13y ago

This assumes the url that process the ?next request pass the info in a Crossdomain way... Ie get vars or post. Everyone does cookies or backend storage. unless you can compromise the target dns, this is impossible to exploit except for very lousy sites... But if they are bad to this point, you probably already have a local shell access

tomvangoethem 13y ago
When you are redirected from Facebook - either after clicking "Accept" or in an implicit flow - to the page with the next parameter, and that page redirects to attacker.com, then attacker.com will have access to the referer header†, which contains the access token. Using this access token, an attacker could extract the sensitive information from the victim's Facebook account. † there are a few exception when referer header isn't shown, e.g. HTTPS->HTTP redirect, but an attacker could make sure that the referer header would be sent for the majority of victims
- gcb0 13y ago
  Always assumed the response was via post... It's silly to use get/url for that. Any ad or external library on the page can already see that then.. Everyone logs referer headers. Even using custom fonts directly from Google is already advertising your tokens...

EGreg 13y ago

I read all the above and I still don't see how the attacker would "gain access" to the user's info on the platform. How do they get the bearer token? ?next=URL is usually implemented to redirect to the URL, and won't propagate the bearer token off the app to the attacker's site. What Am I missing?

deleted 13y ago
[deleted]
kordless 13y ago
Given you implemented it correctly, I would agree with you. A bad implementation would allow for preservation of the URL's parameters ala urllib.urlencode(self.request.params) or similar, which would contain the token.