Re: [OAUTH-WG] Mix-up mitigation is not so easy...

[Warren Parad <[e-mail]>]

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.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.


On Wed, Oct 28, 2020 at 11:08 AM Daniel Fett <[e-mail]> 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
> <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>