Example attack: Example.com accepts authentication from Example-Provider.com
User A wants to login as any other user at Example.com to steal the data that those users have saved at Example.com. User A goes to Example.com and clicks on 'sign in using example-provider.com'; He receives a well-formed request but his browser has a proxy, so the request is cached instead and his browser does not follow the redirect. User A posts on some blog: You can now login to Example.com using Example-Provider.com: Click on this URL. The URL points to Example-Provider.com's authentication endpoint. User B clicks on the link and sees a page at Example-Provider.com asking him/her to authorize Example.com. EV SSL certificates match, everything looks just fine. User B authorizes. However, the page that loads at Example.com (after the redirect) is an error message. bummer. Later, User A crafts a response from Example-provider.com and visits Example.com. He is signed as User B. The attack is possible because _two_ things hold simultaneously. 1. The authentication protocol is not completely executed over a trusted channel between Example.com and Example-Provider.com: the browser channel exposes it to the user. 2. The authenticator does not issue a signature, so attackers can craft responses. Either (1) or (2) would be sufficient to secure the authentication, but both fail in OAuth. In OpenID authentication is secure because 2 holds. Even in stateless authentication there is a signature, and the verification of the signature occurs over a channel that satisfies property 1. I am pretty sure it is possible to prove that a protocol that does not satisfy 1 or 2 is always insecure. I left some details of the attack above left out, but I doubt there are significant technical hurdles to make it work. On Fri, Apr 17, 2009 at 7:39 AM, Eran Hammer-Lahav <[email protected]> wrote: > > And how is it any different from an OpenID request without association? The > RP has to go over to the IDP and ask it if the signed request is valid (as > opposed to if the token/secret pair is valid and authorized). > > EHL > -- Breno de Medeiros --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
