You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a client policy executor to forbid response modes (not just response types)
#44495
Currently, an attacker could use a form of browser swapping attack where they:
start an OIDC authentication process at a client, the client then redirects them to Keycloak at the authorization/authentication endpoint,
the attacker intercepts the redirection and forwards the URL to the victim with an additional response_mode=fragment (whereas the client expects the query or form post response mode).
When the victim is tricked to authenticate (or already authenticated) and Keycloak redirects them to the client, the client doesn't receive the authorization code as it's been passed in the URL fragment.
The attacker could then intercept that URL in the victim's browser and forward the authorization code to their own browser where they can exchange it at the token endpoint.
A variant of this attack is when a client only supports the form post response mode and the attacker changes it to the query response mode. Or it only supports query.jwt and the attacker changes it to query, or the reverse, etc.
There exists mitigations on the client's side, but it looks like something that could be checked by a client policy, complementing the existing reject-implicit-grant executor. One could then configure a client policy to only allow response_mode=query and response_mode=form_post for instance, or enforcing JARM with response_mode=jwt, response_mode=query.jwt and response_mode=form_post.jwt (possibly also fragment.jwt).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Currently, an attacker could use a form of browser swapping attack where they:
response_mode=fragment(whereas the client expects the query or form post response mode).A variant of this attack is when a client only supports the form post response mode and the attacker changes it to the query response mode. Or it only supports query.jwt and the attacker changes it to query, or the reverse, etc.
See https://mailarchive.ietf.org/arch/msg/oauth/TskANcfNy7NNir-hbmcmFASDVog/ and https://medium.com/@anador/attacks-via-a-new-oauth-flow-authorization-code-injection-and-whether-httponly-pkce-and-bff-3db1624b4fa7
There exists mitigations on the client's side, but it looks like something that could be checked by a client policy, complementing the existing
reject-implicit-grantexecutor. One could then configure a client policy to only allow response_mode=query and response_mode=form_post for instance, or enforcing JARM with response_mode=jwt, response_mode=query.jwt and response_mode=form_post.jwt (possibly also fragment.jwt).All reactions