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

["Shuo Chen (MSR)" <[e-mail]>]

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