Hi,
we identified a possible issue regarding the Mix-Up attack
countermeasures described in the Security Best Current Practices.
Section 4.4.2 of the latest version of the BCP lists "AS-specific
redirect URIs" as a countermeasure for Mix-Up attacks.
This countermeasure can be bypassed if Dynamic Client Registration is
used by the client.
The bypass works as follows:
The client will use a unique redirect URI in the Client Registration
Request when it registers at the authorization server operated by the
attacker (A-AS).
However, the A-AS can replace this redirect URI with the same redirect
URI the client uses for the "honest" authorization server (H-AS).
According to RFC7591, the AS is explicitly allowed to replace the
client's requested metadata values and must return all registered
metadata to the client in the Client Information Response. The same
applies to the Client Information Response defined in RFC7592.
For example the client sends the following request:
POST /register HTTP/1.1
{
"redirect_uris": [
"https://client.example.org/attacker-as";],
...
}
The A-AS responds as follows:
HTTP/1.1 201 Created
{
"client_id": "s6BhdRkqt3",
"redirect_uris": [
"https://client.example.org/honest-as"], <-- redirect URI for H-AS
returned by A-AS
...
}
Neither RFC7591/RFC7592 nor the BCP state that the client should
validate the metadata contained in the Client Information Response in
any way.
Depending on its implementation the client might simply extract all data
contained in the Client Information Response and use it for
authorizations with the specific AS.
We were able to confirm that one popular open-source library behaves in
this exact way. It stores the redirect URI contained in the Client
Information Response and uses it for Authorization Requests with the
A-AS although it differs from the redirect URI in the Client
Registration Request.
In our opinion this makes the countermeasure "AS-specific redirect URIs"
obsolete and we believe the other countermeasure described in the BCP
(adding an AS identifier and the client_id of the intended recipient to
AS's responses) should be used to prevent Mix-Up attacks. If the
involved entities use the OIDC hybrid flow this countermeasure is
automatically applied.
Do we miss anything? Or what is your opinion about this?
Best regards,
Karsten Meyer zu Selhausen
--
Phone: (+49)(0)234 / 45930961
Fax: (+49)(0)234 / 45930960
Mail: karsten.meyerzuselhau...@hackmanit.de
PGP: 0EDA AAC6 01DE 3D7F 2123 70F8 4535 C0E7 DB16 F148
Web: www.hackmanit.de
Hackmanit GmbH
Universitätsstraße 150 (ID 2/411)
44801 Bochum, Germany
Vertreten durch: Prof. Dr. Jörg Schwenk, Dr. Juraj Somorovsky, Dr. Christian
Mainka, Dr. Marcus Niemietz
Registergericht: Bochum
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
