ORY Fosite is a security first OAuth2 & OpenID Connect framework for Go. In Fosite from version 0.30.2 and before version 0.34.1, there is an issue in which an an attacker can override the registered redirect URL by performing an OAuth flow and requesting a redirect URL that is to the loopback adapter. Attackers can provide both custom URL query parameters to their loopback redirect URL, as well as actually overriding the host of the registered redirect URL. These attacks are only applicable in scenarios where the attacker has access over the loopback interface. This vulnerability has been patched in ORY Fosite v0.34.1.

ORY Fosite is a security first OAuth2 & OpenID Connect framework for Go. In Fosite before version 0.34.1, the OAuth 2.0 Client's registered redirect URLs and the redirect URL provided at the OAuth2 Authorization Endpoint where compared using strings.ToLower while they should have been compared with a simple string match. This allows an attacker to register a client with allowed redirect URL https://example.com/callback. Then perform an OAuth2 flow and requesting redirect URL https://example.com/CALLBACK. Instead of an error (invalid redirect URL), the browser is redirected to https://example.com/CALLBACK with a potentially successful OAuth2 response, depending on the state of the overall OAuth2 flow (the user might still deny the request for example). This vulnerability has been patched in ORY Fosite v0.34.1.

Impact

When using client authentication method "privatekeyjwt" [[1]](https://openid.net/specs/openid-connect-core-10.html#ClientAuthentication), OpenId specification says the following about assertion jti:

A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties

Hydra does not seem to check the uniqueness of this jti value. Here is me sending the same token request twice, hence with the same jti assertion, and getting two access tokens:

$ curl --insecure --location --request POST 'https://localhost//oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'granttype=clientcredentials' \ --data-urlencode 'clientid=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \ --data-urlencode 'scope=application openid' \ --data-urlencode 'clientassertiontype=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ --data-urlencode 'clientassertion=eyJhb [...] jTw' {"accesstoken":"zeG0NoqOtlACl8q5J6A-TIsNegQRRUzqLZaYrQtoBZQ.VR6iUcJQYp3uj7pwvL7YtPqGhtyQe5OhnBE2KCp5pM","expiresin":3599,"scope":"application openid","tokentype":"bearer"}⏎ $ curl --insecure --location --request POST 'https://localhost//oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'granttype=clientcredentials' \ --data-urlencode 'clientid=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \ --data-urlencode 'scope=application openid' \ --data-urlencode 'clientassertiontype=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ --data-urlencode 'clientassertion=eyJhb [...] jTw' {"accesstoken":"wOYtgCLxLXlELORrwZlmeiqqMQ4kRzV-STU2Sollas.mwlQGCZWXN7G2IoegUe1P0Vw5iGoKrkOzOaplhMSjm4","expiresin":3599,"scope":"application openid","tokentype":"bearer"}

Patches

This issue is patched in 0.31.0.

Workarounds

Do not allow clients to use privatekeyjwt.

References

https://openid.net/specs/openid-connect-core-10.html#ClientAuthentication

In ORY Fosite (the security first OAuth2 & OpenID Connect framework for Go) before version 0.34.0, the TokenRevocationHandler ignores errors coming from the storage. This can lead to unexpected 200 status codes indicating successful revocation while the token is still valid. Whether an attacker can use this for her advantage depends on the ability to trigger errors in the store. This is fixed in version 0.34.0