We need more info on the inject method the researchers used before we can account for it.
Phil On 2012-06-29, at 12:16, John Bradley <ve7...@ve7jtb.com> wrote: > The same thing can be done with code. > > If the token endpoint checks the client_id before giving out the access token > then the attack on code can be prevented, as the token endpoint won't return > the access token. > > The spec dosen't require authenticating public clients currently so it is a > slightly more difficult attack but possible. > > Dick and I are suggesting closing the hole at the token endpoint so that > nether confidential nor public clients using the code flow are susceptible to > this substitution attack. > > John B. > > On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt wrote: > >> I'm not seeing how client id helps if a proxy server is somehow involved >> with inserting the bearer token as the researchers suggested. >> >> Phil >> >> On 2012-06-29, at 11:30, John Bradley <ve7...@ve7jtb.com> wrote: >> >>> I think they only exploited the implicit flow. >>> >>> My point was that there is a way you could do the same thing with code if >>> it is a public client that is not authenticating to the token endpoint. >>> >>> In general making identity assumptions in the client based on a code or >>> access_token has risks that are out of scope for OAuth. >>> >>> We do however want to provide good advice about specific things that can >>> leave systems insecure when using OAuth. >>> >>> John B. >>> >>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote: >>> >>>> I'm not clear whether the MS Security Researcher hack was with the >>>> authorization code or the access token. If the latter, the client_id is >>>> out of the picture isn't it? >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >>>> >>>>> >>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>>>> >>>>>> It is nice to know that I may occasionally be correct:) >>>>> >>>>> You must be delighted when it happens! ;) >>>>> >>>>>> While you may assume that it is reasonable for a client with a code to >>>>>> make a request to the token endpoint including it's client_id and the >>>>>> server to only give out the access token if the client_id in the token >>>>>> request matches the one in the original authorization request. However >>>>>> the spec specifically doesn't require that. >>>>> >>>>> I think that is an error in the spec and should be changed, or text >>>>> adding saying that the client_id SHOULD be checked. >>>>> >>>>> -- Dick >>>>> _______________________________________________ >>>>> 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
