Am 28.10.20 um 12:00 schrieb Warren Parad: > I would likewise assume that issuer validation is always required. But > maybe I hadn't been thinking about this enough. Is there an > alternative to validating it, and implicitly trusting it? Because as > you pointed out either demonstrated control over valid redirect URIs > or really any other secondary mechanism would be required. Perhaps I'm > missing something though.
When using "iss" to mitigate mix-up attacks, we're essentially telling the client where submitting the auth code is okay. Since this chain of pointers starts at the AS (→ issuer ID → metadata document → token endpoint URL), there's no further validation needed: In this direction, we can assume that every pointer points to an uncompromised component. A malicious issuer could mix and match PAR/authorization/token/userinfo endpoint URLs and thereby build a different chain, but I think there's really not that much that can go wrong there that wouldn't be covered by the "iss" defense: https://danielfett.de/2020/05/04/mix-up-revisited/ -Daniel > On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett <f...@danielfett.de > <mailto:f...@danielfett.de>> wrote: > > Hi all, > > during my work to update the Security BCP, I stumbled upon a > problem in our current recommendations against mix-up attacks. > > Until now, our understanding was that adding an "iss" parameter in > the authorization response and using a distinct redirect URI for > each configured issuer provided the same level of security. This > is unfortunately not the case when mix-up is combined with a > client impersonation attack. > > Let's start with the "iss" parameter: The assumption is, that an > AS "knows" which issuer it belongs to. Therefore, an uncompromised > AS will always send the identifier for this (correct) issuer in > the "iss" parameter in the authorization response. The client will > see that it started the process with the attacker's issuer, but > receives the identifier for another issuer in the authorization > response, and will abort the interaction. > > With the distinct redirect URIs, the situation is similar. Let's > look at how the client would defend against mix-up: > > * For the attacker's AS configuration (attacker Authorization > Endpoint, attacker Token Endpoint), the client would register > https://client.com/redir/attacker as the redirection URI at > the attacker's AS. > * For the honest AS configuration (honest Authorization > Endpoint, honest Token Endpoint), the client would register > https://client.com/redir/honest as the redirection URI at the > honest AS. > > In the normal mix-up attack, the following would happen: > > * The user selects "attacker" as AS. > * The user is being redirected to the attacker's authorization > endpoint. > * The attacker redirects the user to the honest AS's > authorization endpoint, replacing the client ID in the > original authorization request with the client ID of the > client at the honest AS. > * The user authorizes the client at honest AS. > * Honest AS redirects the user back to the client, using > https://client.com/redir/honest as the redirect URI. > * The client notices a mismatch between the redirection URI and > the expected redirect URI (which would be .../attacker). > > Therefore, the mix-up attack is mitigated. The problem is, > however, that the attacker can circumvent the protection by > *registering a new client with the honest AS, giving > https://client.com/redir/attacker as the redirection URI* and > using this new client ID in step 3 of the attack. > > This would mean that the client would see the attacker's redirect > URI as the incoming URI for the authorization response and would > not detect the attack. It would forward the authorization code to > the token endpoint of the attacker, who would be able to redeem it. > > Note that the user would not grant access to the honest client, > but to the attacker's client. The attacker's client would need to > "impersonate" the honest client, i.e., using the same name, icon, > etc.; This approach is similar to existing OAuth phishing attacks > with counterfeit clients, however, in this case, a *redirect URI > of the honest client* is used. Therefore, the usual mitigation > whereby the AS shows the redirect URI to the user would not > provide any protection (see also > https://tools.ietf.org/html/rfc6819#section-3.5). > > What can we do against this attack? > > * PKCE does not protect against this attack, as the attacker > would be able to change the code_challenge parameter. > * I think that PAR and JAR probably won't help either, since the > honest client "legitimately" speaks to the attacker's AS, who > in turn speaks "legitimately" to the honest AS (as the > attacker's client). All sides would use the correct endpoints > and keys, and the attacker would be able to receive and modify > the authorization request, forwarding it to the honest AS > under his own client ID. > * For the same reason, a DPoP-like sender-constraining of the > authorization code is unlikely to help. > * What would help is if client registrations would depend on an > ACME-like demonstration of control over the origin of the > redirect URI. This not something mandated for OAuth today and > is unlikely to be seen in broad use. > * The "iss" parameter solution is robust against this attack as > long as an authorization server never returns an issuer > controlled by the attacker. In essence, by declaring the > issuer, the AS is providing a pointer to a metadata file which > points to the "correct" token endpoint - this is why this > solution is robust. We have shown the robustness of the "iss" > solution in our formal analysis, but never analyzed the > redirect uri solution formally. > > For the security BCP, this means that we depend on the "iss" > parameter solution even more. (It also means that OAuth 2.1 should > probably include this parameter.) > > We need to think about how we can proceed with the security BCP > without too much delay. > > Sorry for poking another hole into the spec, > Daniel > > -- > https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
