4 ms·

Actual source: http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html http://tetraph.com/covert_redirect/oauth2_openid_covert_redi... I was expe

Actual source: http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html http://tetraph.com/covert_redirect/oauth2_openid_covert_redi... I was expecting an authentication bypass vulnerability, but this is just an open redirect. It is not "serious".

nailer 13y ago
I'm relatively familiar with oAuth 2, but I don't quite grok this. So, normally: I, a site that uses oauth to authorize someone Google / Twitter etc account register a redirect URI where people, after authorizing / denying, are sent with a access key. The vuln is that my redirect URI can be exploited someone to send users onto a different site, with their access key? How could an attacker manipulate a URL to redirect somewhere else? Content injection? Like some users whose name is a script that changes window.location? Doesn't nearly every templating language explicitly require special stuff like {{{ }}} for unsafe content? If that's correct, it seems a little overblown. But maybe I'm wrong.
- davewhat 13y ago
  The flow does not originate at your site. Your site did not create the redirect URI that is being passed to Google / Twitter in your example. The URL is generated by a malicious party. The URL constructed (1) sends the user to Google / Twitter for authentication, (2) includes a return URL of your open redirector, and (3) has your open redirect send you on to an evil site.
  - nailer 13y ago
    > Your site did not create the redirect URI that is being passed to Google / Twitter in your example. Sorry, I don't understand this sentence. The redirect URI is not normally passed to Google / FB / Instagram dynamically, but normally registered with Google / FB / Instagram once, when you set up an app with them (and get a secret key etc). If someone else registered their own app with their own redirector, they wouldn't have my secret key. Edit: removed Twitter, they use oAuth 1 which is strange / different / weird.
    - icebraining 13y ago
      No, you do pass the URI dynamically, it's a required part of the Access Token Request: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.1.3 http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.... It's just that with a decent implementation, you should also be required to register it beforehand with the provider.
      - vertex-four 13y ago
        Not just a decent implementation; an implementation which meets the spec. This is not a problem with OAuth2, which explicitly requires registration of URIs where the implicit grant type is used, and covers other cases well in the Security Considerations section.
        nailer 13y ago
        That makes a lot of sense: I've only really dealt with oAuth 2, as oAuth 1.0a is vastly more complicated and only Twitter seems to still use it. Thanks icebraining & vertex-four.
- melville_X 13y ago
  From the Q&A: > Covert Redirect is based on vulnerability Open Redirect. An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation (OWASP). So Covert Redirect is an applicaiton that takes a paramter and redirects a user to the parameter value with improper validation. Usually this is the of result of overconfidence of its partnership. Seems like a known flaw in OAuth2.
- kordless 13y ago
  > 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
tveita 13y ago
I think this is even covered in the spec. The authorization server MUST require the following clients to register their redirection endpoint: o Public clients. o Confidential clients utilizing the implicit grant type. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint. http://tools.ietf.org/html/rfc6749#section-3.1.2.2 http://tools.ietf.org/html/rfc6749#section-3.1.2.2
- kodablah 13y ago
  The OAuth servers I have developed have done like GitHub does [1] and at least confirm the redirect given during auth starts with the application-level URI. I think it gives plenty of flexibility while still not openly redirecting. Edit: Or maybe I don't understand the flaw since it says GitHub is vulnerable... 1 - https://developer.github.com/v3/oauth/#redirect-urls https://developer.github.com/v3/oauth/#redirect-urls
- cratermoon 13y ago
  Good Oauth2.0 and later implementations enforce this. Note that Twitter does not fall into that category.
jlafon 13y ago
I'm trying to understand this too. This is only a problem if the OAuth provider (Google, Twitter, etc) does not validate the URL that the client is trying to redirect the user to after the user has authorized the app, correct?
- patio11 13y ago
  Typically you pre-register a whitelist of redirect URLs with your OAuth provider. For example, you might whitelist example.com/app/* because you control the app and assume that you won't do anything evil. If /app/ includes an open redirect (generally considered to be Severity: Nominal), your application can be made to attack every user who grants it permissions, to the limit of the permissions they entrust your application with.

nailer 13y ago

I'm relatively familiar with oAuth 2, but I don't quite grok this. So, normally: I, a site that uses oauth to authorize someone Google / Twitter etc account register a redirect URI where people, after authorizing / denying, are sent with a access key. The vuln is that my redirect URI can be exploited someone to send users onto a different site, with their access key? How could an attacker manipulate a URL to redirect somewhere else? Content injection? Like some users whose name is a script that changes window.location? Doesn't nearly every templating language explicitly require special stuff like {{{ }}} for unsafe content? If that's correct, it seems a little overblown. But maybe I'm wrong.

davewhat 13y ago
The flow does not originate at your site. Your site did not create the redirect URI that is being passed to Google / Twitter in your example. The URL is generated by a malicious party. The URL constructed (1) sends the user to Google / Twitter for authentication, (2) includes a return URL of your open redirector, and (3) has your open redirect send you on to an evil site.
- nailer 13y ago
  > Your site did not create the redirect URI that is being passed to Google / Twitter in your example. Sorry, I don't understand this sentence. The redirect URI is not normally passed to Google / FB / Instagram dynamically, but normally registered with Google / FB / Instagram once, when you set up an app with them (and get a secret key etc). If someone else registered their own app with their own redirector, they wouldn't have my secret key. Edit: removed Twitter, they use oAuth 1 which is strange / different / weird.
  - icebraining 13y ago
    No, you do pass the URI dynamically, it's a required part of the Access Token Request: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.1.3 http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.... It's just that with a decent implementation, you should also be required to register it beforehand with the provider.
    - vertex-four 13y ago
      Not just a decent implementation; an implementation which meets the spec. This is not a problem with OAuth2, which explicitly requires registration of URIs where the implicit grant type is used, and covers other cases well in the Security Considerations section.
      - nailer 13y ago
        That makes a lot of sense: I've only really dealt with oAuth 2, as oAuth 1.0a is vastly more complicated and only Twitter seems to still use it. Thanks icebraining & vertex-four.
melville_X 13y ago
From the Q&A: > Covert Redirect is based on vulnerability Open Redirect. An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation (OWASP). So Covert Redirect is an applicaiton that takes a paramter and redirects a user to the parameter value with improper validation. Usually this is the of result of overconfidence of its partnership. Seems like a known flaw in OAuth2.
kordless 13y ago
> 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

tveita 13y ago

I think this is even covered in the spec. The authorization server MUST require the following clients to register their redirection endpoint: o Public clients. o Confidential clients utilizing the implicit grant type. The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint. http://tools.ietf.org/html/rfc6749#section-3.1.2.2 http://tools.ietf.org/html/rfc6749#section-3.1.2.2

kodablah 13y ago
The OAuth servers I have developed have done like GitHub does [1] and at least confirm the redirect given during auth starts with the application-level URI. I think it gives plenty of flexibility while still not openly redirecting. Edit: Or maybe I don't understand the flaw since it says GitHub is vulnerable... 1 - https://developer.github.com/v3/oauth/#redirect-urls https://developer.github.com/v3/oauth/#redirect-urls
cratermoon 13y ago
Good Oauth2.0 and later implementations enforce this. Note that Twitter does not fall into that category.

jlafon 13y ago

I'm trying to understand this too. This is only a problem if the OAuth provider (Google, Twitter, etc) does not validate the URL that the client is trying to redirect the user to after the user has authorized the app, correct?

patio11 13y ago
Typically you pre-register a whitelist of redirect URLs with your OAuth provider. For example, you might whitelist example.com/app/* because you control the app and assume that you won't do anything evil. If /app/ includes an open redirect (generally considered to be Severity: Nominal), your application can be made to attack every user who grants it permissions, to the limit of the permissions they entrust your application with.