I support keeping those two in a single document. They actually belong to a same class of problem: the problem of accepting an input from an untrusted / un-protected source, i.e., the authorization response. When this vulnerability is applied to the 'state', it opens up the chance of authorization code being stollen through a rogue token endpoint. When it is applied to the authorization code, then it is a cut-n-paste attack.
The reason why 'code id_token' response type is protected in OIDC is that the authorization response is integrity protected and the origin authenticated. Nat 2016年2月6日(土) 23:59 John Bradley <ve7...@ve7jtb.com>: > I think Toresen states it well. > > The reason we looked at 2 again is that #1 in some of the attacks was > being used to leak the code. > In some of those cases the attacker had the client credentials and could > use the directly to get access tokens. > > In other cases the attacker doesn’t have the client credentials, but could > still get access to the information protected by the API by presenting the > code back to the client as part of a new flow, and bind it to a new account > or if the clint is unwise and using the code for authentication, > impersonate the user. > > There are certainly other ways an attacker could get code, via logs, open > redirectors etc. > The closest mention of this in 6819 is sec 4.4.1.13 , but that considered > two clients with two client_id. > that was mitigated by having the client send it’s client_id with code to > exchange it. > > The difference with 2 is that only one client_id is used, and that is not > mitigated by the current counter measures in 6819. > > Perhaps referring to 6819 sec 4.4.1.13 is a distraction, in this case. > We however were concerned at the time about codes leaking and being > replayed but missed some of the ways that could happen. > > The two opportunities that we are leaving for attackers, 1 not knowing > who is sending the authorization response, and not tying the authorization > request and response to the same browser instance open a whole world of > attacks. > > What we think currently is that there are two basic flaws that are being > exploited (some attacks use one or the other and some use them together) . > We should probably keep the fixes separate from documents that are more > how to guides to attack un-patched clients. > > Both issues are around the client being mislead or confused by an > authorization response, in that it is coming back from the wrong place or > in the wrong browser instance. That is why the two mitigations probably > belong in the same document. > > John B. > > > > On Feb 6, 2016, at 8:32 AM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote > > > Hi Hannes, > > #2 is not directly described in the paper but was used to replay the > code/token the attacker obtained via #1. In my observation, the discussion > in Darmstadt has shown that OAuth (and its built-in mitigations) so far > focused on preventing code/token leakage but we lake mitigation for replay > in this particular case. > > #2 does not require the attacker to control the network or the victim's > device. The attacker (using #1 or other attacks, e.g. on referrer headers > or log files) obtains a code and injects this code into a legitimate > OAuth/OIDC flow on its device. All she has to do is starting a authz code > flow on the legitimate client, the particular code was issued for, and > replace the code in the response from the AS. From the client's > perspective, the response looks ok, since it carries the correct state > value bound to the client in the particular user agent (since this is not a > XSRF). But since there is no way (currently) to bind the code to a certain > user agent, the client would accept the code and exchange it for token(s) > on the AS. That gives the attacker access to resources of the victim and/or > impersonates the attacker as the victim. > > There are several way to mitigate this issue: > - OIDC has the "code id_token" response type, which uses nounce and c_hash > in the id_token to bind the code to the user agent session > - in Darmstadt we came up with the idea to utilize the state value for > that purpose. > > Do we need to describe the threat and mitigation if > draft-jones-oauth-mix-up-mitigation? I don't think so. > We could describe the mechanisms in a different draft. > > I personally would prefer (and Phil already states this as well) the WG to > work on a single draft, providing a consolidated view on all threats caused > by the more dynamic usage of OAuth. We could also include all > threats/mitigations/issues we have seen in the wild since RFC 6749 was > published. This would also include stronger advice regarding XSRF > prevention and open redirectors. I don't think we serve the community well > be spreading those issues and mitigation over 3 or 4 drafts. > > best regards, > Torsten. > > Am 04.02.2016 um 21:27 schrieb Hannes Tschofenig: > > Hi all, > > when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation' > solution <draft-jones-oauth-mix-up-mitigation> I wasn't expecting such a > heavy debate on the list. While the call for adoption is still ongoing I > would like to share my view as someone who has to judge consensus in a > few days together with Derek. > > Regardless of where we are with respect to oauth-meta vs. > draft-jones-oauth-mix-up-mitigation we should keep an eye on the threats > we are trying to address (and we have to document them). > > Here is how I would summarize the situation after reviewing the drafts, > blog posts and various emails sent to the list. > > > We have two types of threats: > > #1: Threat described in the papers referenced in my email to the > listhttp://www.ietf.org/mail-archive/web/oauth/current/msg15336.html > > The attack assumes that '... the presence of a network attacker who can > manipulate the request in which the user sends her identity to the RP as > well as the corresponding response to this request ...' (see page 15 > ofhttp://arxiv.org/pdf/1601.01229v2.pdf). > > I believe that this threat is well documented (at least in the paper). > > #2: Cut-and-Paste Attacks > > Here things get a bit more difficult since the threat is less well > described. In Section 7.3 > ofhttps://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 Mike > makes an attempt to describe the attack and refers to Section 4.4.1.13 > of RFC 6819, which talks about 'Code Substitution'. I am not convinced > that the description in RFC 6819 exactly matches the intention of > Section 7.3 of draft-jones-oauth-mix-up-mitigation-01 but I might be > misinterpreting. > > Anyway, here is a copy-and-paste from the draft: > > A "cut-and-paste" attack is performed > by the attacker creating what appears to be a legitimate > authorization response, but that substitutes some of the response > parameter values with values of the attacker's choosing. > > Clearly, this attack makes different assumptions than what is stated in > the papers listed under item #1. It appears that the attacker will have > to be on the users device /browser itself. If that's true then the text > needs to state that. > > Nat also provides a description of a similar attack in his blog post > under the name of 'Code Phishing' > athttp://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ > In his description the attacker assumption is that the developer is > tricked into re-configuring the token endpoint so that the attacker is > able to obtain the authorization code. > > While I believe the group is well advised to tackle the attack described > in item #1 to mitigate the attacks discovered late last year. I am > curious whether the group also sees the mitigation of threat #2 in scope > of this document. In some sense, one could argue that cut-and-paste is > more generic and a concern also for those cases where an OAuth client > does not talk to multiple ASs. > > So, here are my questions: > > - Can we describe the threat #2 in more details and by stating the > assumptions about the attacker? > > I believe that this is important for understanding the attack within the > participants of the group but also for those who stumble over our > documents. Once we have a good description we should move on and answer > the next two questions: > > - Should the document describe mitigations for attacks #1 and #2? > > - Should the solution mandate a solution for dealing with both attacks? > > Finally, we can talk about the details of the attack mitigation itself. > > As far as the work from Mike (oauth-mix-up-mitigation) and Nat > (oauth-meta) is concerned Derek and I will find ways to ensure that the > prior work by all involved participants is appropriately attributed and > acknowledged! > > Ciao > Hannes > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
