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:de...@ihtfp.com] >>> > 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)" <shuoc...@microsoft.com> 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 oauth@ietf.org mailing list? >>> > >>> >> Thanks a lot. >>> >> >>> >> -Shuo >>> > >>> > -derek >>> > >>> >> -----Original Message----- >>> >> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] >>> >> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
