-
Notifications
You must be signed in to change notification settings - Fork 14
Signature Bypass
Header: {
--> "alg": "HS256" <--
}
Body: {
"iss": "http://openidConnectProvider.com/",
"sub": "user1",
"exp": 1444148908,
"iat": 1444148308,
"nonce": "40c6b33b9a2e",
"aud": "client_id",
}
Signature: --> AF45JF93LKD76D.... <--
Signature Bypass is an attack which targets the ID Token verification part of a Client. If the signature verification by a Client is not handled correctly, an attacker may be able to login as an arbitrary End-User of this application: To perform a attack an attacker has to act as an End-User only.
Let the ID Token of the victim be represented by tV = I**DV||sV where I**DV = subV : issV and sV is the signature or HMAC of I**DV. In theory, an attacker should not be able to alter the content of her ID Token tA = I**DA||sA to, for example, t* = I**DV||s. If the attacker uses an Authentication Flow (e.g. Implicit) where she has direct access to the issued ID Token and alters the intercepted token as described above and if the Client accepts t*, the attack is successful (and the attacker should be logged in with I**DV).
There are different possibilities to achieve this goal.
If the Client does not to validate the signature at all, the attacker can inject arbitrary content in the ID token. The signature validation is enforced in the OIDC Specification, Section 3.2.2.11, Step 1.
It is possible to create a valid JWT token by setting the alg
parameter in the JWT header to none
. The algorithm is not allowed in the implicit flow (see OIDC Specification, Section 2), but if the implementation just uses a validateToken()
method without checking if the none
algorithm is used (and allowed!), this leads to serious security problems – the attacker can impersonate any End-User on the Client.
From a developer perspective, using the same code for validating a token is very useful. However, in OIDC, there must be a clear distinction between the implicit and the code flow.