Impact
fosite#400 (released as v0.30.2) introduced a new feature for handling redirect URLs pointing to loopback interfaces (rfc8252#section-7.3). As part of that change new behavior was introduced which failed to respect the redirect URL's (only for loopback interfaces!) query parameters
- Registering a client with allowed redirect URL
http://127.0.0.1/callback
- Performing OAuth2 flow and requesting redirect URL
http://127.0.0.1/callback?bar=foo
- Instead of an error, the browser is redirected to
http://127.0.0.1/callback?bar=foo
with a potentially successful OAuth2 response.
as well as the host parameter (as long as the host is a loopback interface):
- Registering a client with allowed redirect URL
https://example.com/callback
- Performing OAuth2 flow and requesting redirect URL
http://127.0.0.1/callback
- Instead of an error, the browser is redirected to
http://127.0.0.1/callback
with a potentially successful OAuth2 response.
These bugs are only applicable in scenarios where the attacker has control over the loopback interface (localhost
, 127.0.0.1
, [::1]
) where the browser performing the OAuth2 flow is running.
References
Impact
fosite#400 (released as v0.30.2) introduced a new feature for handling redirect URLs pointing to loopback interfaces (rfc8252#section-7.3). As part of that change new behavior was introduced which failed to respect the redirect URL's (only for loopback interfaces!) query parameters
http://127.0.0.1/callback
http://127.0.0.1/callback?bar=foo
http://127.0.0.1/callback?bar=foo
with a potentially successful OAuth2 response.as well as the host parameter (as long as the host is a loopback interface):
https://example.com/callback
http://127.0.0.1/callback
http://127.0.0.1/callback
with a potentially successful OAuth2 response.These bugs are only applicable in scenarios where the attacker has control over the loopback interface (
localhost
,127.0.0.1
,[::1]
) where the browser performing the OAuth2 flow is running.References