Subject: [OAUTH-WG] OAuth2 attack surface....

From: William Mills <[email-masked]>
Date: Mon, 25 Feb 2013 14:22:24 -0800 (PST)

I think this is worth a read, I don't have time to dive into this :(

---

From: William Mills <[email-masked]>
Date: Mon, 25 Feb 2013 14:42:13 -0800 (PST)

DOH!!!  http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html

________________________________
 From: Phil Hunt <[email-masked]>
To: William Mills <[email-masked]> 
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <[email-masked]> wrote:

I think this is worth a read, I don't have time to dive into this :(
_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 25 Feb 2013 22:58:48 +0000

>From my read, it's a combination of browser bugs (it only affects Chrome) and Facebook's insistence on using the Implicit flow for everything.

While I don't at all care for the "sky is falling" rhetoric that seems to follow OAuth2, the author has some good suggestions for implementations: binding redirect URIs to particular flows, preference for the code flow, not using a default redirect_uri on a hosted domain with user-generated content.

But all of these are implementation issues that the OAuth2 protocol can't really address directly.

-- Justin

On Feb 25, 2013, at 5:42 PM, William Mills <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface....

Whats the link?

Phil

Sent from my phone.

On 2013-02-25, at 14:22, William Mills <[email-masked]<mailto:[email-masked]>> wrote:

I think this is worth a read, I don't have time to dive into this :(
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Feb 2013 15:18:26 -0800

Agreed, though we can't assume that there won't be other browser bugs that can be exploited in similar ways. 

Facebook automatically adding there debug page to the redirect URI of every client was...

We need to reenforce care around redirect URI, Connect is much more restrictive than OAuth. 

I think client registering it's response types is a good idea,  I see it is already in the IETF registration spec.

John B.

On 2013-02-25, at 2:58 PM, "Richer, Justin P." <[email-masked]> wrote:

> On Feb 25, 2013, at 5:42 PM, William Mills <[email-masked]> wrote:
> 
>> 
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Feb 2013 17:42:05 -0800

I once again kick myself for not noticing the implicit flow was inserted into the spec … hopefully the warning labels keep others from supporting the implicit flow … but additional messaging about not supporting implicit flow would be useful.

I can see why Facebook wanted it for the content merging it provides, but it should likely have been a different API and authorization process.

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 26 Feb 2013 07:22:43 +0000

And a different one (still exploiting redirection and still implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

Regards

Antonio

On Feb 25, 2013, at 11:42 PM, William Mills wrote:

Whats the link?

Phil

Sent from my phone.

---

From: prateek mishra <[email-masked]>
Date: Thu, 28 Feb 2013 17:56:17 -0500

Characteristics of both these attacks -

1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one 
case only)

- prateek
> And a different one (still exploiting redirection and still 
> implementation mistake) 
> http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html 
>
>
> Regards
>
> Antonio
>
>> DOH!!! 
>> http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html
>>
>> ------------------------------------------------------------------------
>> *From:* Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> *To:* William Mills <[email-masked] 
>> <mailto:[email-masked]>>
>> *Sent:* Monday, February 25, 2013 2:28 PM
>> *Subject:* Re: [OAUTH-WG] OAuth2 attack surface....
>>
>> Whats the link?
>>
>> Phil
>>
>> Sent from my phone.
>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Oleg Gryb <[email-masked]>
Date: Thu, 28 Feb 2013 17:45:48 -0800 (PST)

I don't like that "implicit flow" or former user-agent much and wrote about it 2 years ago, but that attack is rather related to implementation bugs, not to protocol itself. A root cause - a bug in redirect URL verification (probably  a regexp flaw).

Enforcing token's life time at a protocol level doesn't make too much sense either, because it should depend on sensitivity of protected data. 

The same is true about the scope.

I think, the latter two issues have been already reflected in the Torsten's TM.

--- On Thu, 2/28/13, prateek mishra <[email-masked]> wrote:

From: prateek mishra <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth2 attack surface....
To: "[email-masked]" <[email-masked]>
Date: Thursday, February 28, 2013, 5:56 PM

  

    2) changes to redirect uri (specification does allow some
    flexibility here)

    3) applications with long-lived access tokens with broad scope (in
    one case only)

    - prateek

    And a different one (still exploiting redirection and
      still implementation mistake) http://www.nirgoldshlager.com/2013/02/how-i-hacked-facebook-oauth-to-get-full.html

      Regards

      Antonio

          

                

                      

                          

                                   From:
                                  Phil Hunt <[email-masked]>

                                  To:
                                  William Mills <[email-masked]>

                                  Sent:
                                  Monday, February 25, 2013 2:28 PM

                                  Subject:
                                  Re: [OAUTH-WG] OAuth2 attack
                                  surface....

                                
                                  Whats the link?

                                    Phil

                                    Sent from my phone.

                                    On 2013-02-25, at 14:22, William
                                    Mills <[email-masked]>
                                    wrote:

                                      
                                        I think this is worth a
                                          read, I don't have time to
                                          dive into this :(

                                  

                                      OAuth mailing list

                                      [email-masked]

                                  

                            

                    

            OAuth mailing list

            [email-masked]

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 19:21:45 -0800

While implicit is what they are attacking, this is in principal also possible to do with a code flow if the client is public.
It is only confidential clients using the code flow that have reasonable protection from open redirectors.

In openID Connect we made registered redirect_uri and full comparison of the URI including query parameters a requirement.

Allowing path or query parameters outside of the redirect comparison leaves too large of an uncontrolled attack surface.

Implementation mistakes are almost inevitable. 

John B.
On 2013-02-28, at 2:56 PM, prateek mishra <[email-masked]> wrote:

> 3) applications with long-lived access tokens with broad scope (in one case only)
> 
> - prateek