Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

[Dick Hardt <[e-mail]>]

John

Do you have suggested text per your suggestion below?

-- Dick

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

> I blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
> 
> Nov Matake and others built some tests and found quite a number of deployments vulnerable. 
> http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
> 
> The bottom line is that OAuth has no explicit audience restriction for tokens,  hence accepting any token outside of the code flow is subject to attack.
> 
> In general it is not a issue for authorization,  it is however a big issue then there is a presumption that the presenter of a token that grants a client access to resource x is the "resource owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x.
> 
> We might want to include the why it is insecure in the security consideration,  otherwise people reading the below will likely ignore the advice as it seems on the surface a touch extreme.
> 
> There are certainly OAuth flows that allow you to do authentication safely,  just not all of them without additional precautions.
> 
> That is why openID Connect has a audience restricted id_token similar to Facebook's signed request to allow the implicit flows to be safely used for authentication.
> 
> John B.
> 
> 
> 
> 
> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:
> 
>> Hi OAuth group,
>>  
>> This is regarding the recent discussion about an implementation issue of some cloud services using OAuth for authentication.
>> Derek Atkins and Dick Hardt suggested the possibility to discuss with the group a paragraph to add to the security considerations section.
>>  
>> Derek’s suggestion:
>> ====   ===  ===  ===
>> >> Perhaps you could boil it down to a paragraph
>> >> or two for addition to the security considerations section that basically says
>> >> "beware of implementing it *this* way because it leads to *that* attack vector", etc.
>> ====   ===  ===  ===
>>  
>>  
>> Here is out suggested text:
>> ====   ===  ===  ===
>> It has been observed that in multiple occasions that the server-side
>> authentication logic takes an access token from the client, then
>> queries the user's profile data from the IdP in order to
>> "authenticate" the user. This implementation must be forbidden. It
>> will allow an untrusted app running on a victim’s client device to
>> work with an attacker’s device to sign into the victim’s account on the server side.
>> ====   ===  ===  ===
>>  
>>  
>> Thank you.
>> -Shuo
>> p.s. below is the email thread giving a better context of the discussion.
>>  
>>  
>> > -----Original Message-----
>> > From: Derek Atkins [mailto:[e-mail]]
>> > Sent: Monday, June 18, 2012 11:25 AM
>> > To: Shuo Chen (MSR)
>> > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
>> > Atkins; Dick Hardt
>> > Subject: Re: [OAUTH-WG] web sso study...
>> > 
>> > Hi,
>> > 
>> > "Shuo Chen (MSR)" <[e-mail]> writes:
>> > 
>> >> Hi Hannes, Derek and Stephen,
>> >> 
>> >> Thank you for your replies.
>> >> 
>> >>> First, let me ask whether it is OK if I share your post with the
>> >>> OAuth WG
>> >> 
>> >> Yes, please feel free to share it.
>> >> 
>> >>> Second, could you describe the attack in more details to me?
>> >> 
>> >> Let's consider the mobile+cloud scenario for concreteness (although
>> >> some other scenarios are also applicable). The attack steps are the
>> >> following: suppose Alice's tablet runs a Windows 8 Metro app written
>> >> by attacker Bob. This app is able to request and obtain an access
>> >> token from the IdP (associated with Alice). The app can then send the
>> >> access token to Bob's own tablet. Note that there is no security
>> >> problem up to this point. However the real problem is that some cloud
>> >> services use the access token to query the user's profile data from
>> >> the IdP in order to "authenticate" the user. In this case, Bob's
>> >> tablet will be able to sign into the cloud service as Alice. We have
>> >> confirmed that the cloud services for Soluto Metro App, Givit Metro
>> >> App and EuroCup2012 Metro App make this mistake. These are apps in
>> >> the official Windows 8 App Store. We actually sampled only a small portion of the available apps, but believe this is a vulnerability pattern.
>> >> 
>> >> We don’t think there is anything wrong in the OAuth spec. It is
>> >> developers who didn’t comprehensively understand the usage of the
>> >> access token. In the meanwhile, this vulnerability pattern is not explicitly excluded by the spec.
>> >> More importantly, it has been seen in the wild.
>> >> 
>> >>> [from Derek's email] Perhaps you could boil it down to a paragraph
>> >>> or two for
>> >> addition to the security considerations section that basically says
>> >> "beware of implementing it *this* way because it leads to *that* attack vector", etc.
>> >> 
>> >> This is a great idea. I think that although it is difficult to
>> >> anticipate in general all kinds of incomprehensive understandings of
>> >> average developers, it is very worthwhile to take any common existing
>> >> vulnerability pattern as a precious feedback to improve the
>> >> specification text. In this case, since we have already seen this
>> >> vulnerability pattern on multiple services in the wild, certainly we
>> >> should be explicit about it in the security considerations section.
>> >> 
>> >> Our suggested text:
>> >> 
>> >> It has been observed that in multiple occasions that the server-side
>> >> authentication logic takes an access token from the client, then
>> >> queries the user's profile data from the IdP in order to
>> >> "authenticate" the user. This implementation must be forbidden. It
>> >> will allow an untrusted app running on a victim’s client device to
>> >> work with an attacker’s device to sign into the victim’s account on the server side.
>> >> 
>> >> Any questions or suggestions?
>> > 
>> > Could you please send this to the [e-mail] mailing list?
>> > 
>> >> Thanks a lot.
>> >> 
>> >> -Shuo
>> > 
>> > -derek
>> > 
>> >> -----Original Message-----
>> >> From: Hannes Tschofenig [mailto:[e-mail]]
>> >> Sent: Friday, June 15, 2012 11:36 AM
>> >> To: rui wang
>> >> Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
>> >> Derek Atkins
>> >> Subject: Re: [OAUTH-WG] web sso study...
>> >> 
>> >> Hi Rui,
>> >> 
>> >> let me independently respond (in addition to the previous responses
>> >> you had already gotten).
>> >> 
>> >> First, let me ask whether it is OK if I share your post with the
>> >> OAuth WG since it is more detailed than the one you distributed on the list mid April.
>> >> 
>> >> Second, could you describe the attack in more details to me? What I
>> >> would like to better understand whether this the raised issue is a
>> >> problem with one of our specifications, with a specific
>> >> implementation of the IETF OAuth specifications, a problem with other
>> >> OAuth related work (Facebook, as you know, implements far more than
>> >> just the IETF OAuth specifications), a violation of the IETF OAuth
>> >> specification in the way how the Websites use OAuth, whether this is
>> >> a configuration related aspect, or an aspect we already documented in the threats document.
>> >> 
>> >> The reason why I am so specific is to know where to put text to
>> >> address this issue or whether this is even an issue beyond the IETF
>> >> OAuth working group and needs to be tackled somewhere else.
>> >> 
>> >> Ciao
>> >> 
>> >> Hannes
>> >>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth