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

[John Bradley <[e-mail]>]

I can put something together.   

It is mostly a warning about the token substitution attack that any implicit flow is vulnerable to if used for authentication of the presenter.
Otherwise known as why audience restriction is a good thing.

John B.

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

> 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
>