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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
