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
https://www.ietf.org/mailman/listinfo/oauth
