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

From: prateek mishra <[email-masked]>
Date: Fri, 01 Mar 2013 10:00:48 -0500

Yup, use of confidential clients and full checking of redirect URIs 
would mitigate these attacks.

I think there is an issue of providing guidance to developers/deployers, 
about making secure choices, that needs to be addressed someplace. A 
test suite
would also be a good complement to a document.

One challenge is that OAuth addresses such a broad class of clients - 
from angry birds all the way to transactional apps. I am a mostly interested
in the latter, it would be good to have a resource that i can point 
people to (and, yes, the TM document is good but I dont see it as 
something most developers/deployers would
  benefit from).

- prateek

> 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] 
> <mailto:[email-masked]>> wrote:
>
>> 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
>>>
>>> On Feb 25, 2013, at 11:42 PM, William Mills wrote:
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [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: Antonio Sanso <[email-masked]>
Date: Fri, 1 Mar 2013 15:44:09 +0000

On Mar 1, 2013, at 4:00 PM, prateek mishra wrote:

Yup, use of confidential clients and full checking of redirect URIs would mitigate these attacks.

I think there is an issue of providing guidance to developers/deployers, about making secure choices, that needs to be addressed someplace. A test suite
would also be a good complement to a document.

do you mean having a TCK for OAuth 2.0?

One challenge is that OAuth addresses such a broad class of clients - from angry birds all the way to transactional apps. I am a mostly interested
in the latter, it would be good to have a resource that i can point people to (and, yes, the TM document is good but I dont see it as something most developers/deployers would
 benefit from).

- prateek

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.

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

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.

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

_______________________________________________
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

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

---

From: prateek mishra <[email-masked]>
Date: Fri, 01 Mar 2013 13:50:26 -0500

>> I think there is an issue of providing guidance to 
>> developers/deployers, about making secure choices, that needs to be 
>> addressed someplace. A test suite
Yes, that is the general direction I was thinking of but in a language 
independent format.

An example is the XACML 2.0 conformance suite:

https://www.oasis-open.org/committees/download.php/14846/xacml2.0-ct-v.0.4.zip

Of course, testing AS and RS would involve network exchanges, so it 
would be a bit more involved...