In this lesson,
we're going to talk about attacks against OpenID Connect,
also known as OIDC.
OpenID Connect is an identity layer
built on top of the OAuth 2.0 protocol,
allowing clients to verify the identity of end users
based on the authentication
performed by an authorization server.
The OIDC is commonly used for single sign-on scenarios
where users can log in once
and gain access to multiple applications.
Just as a quick refresher, here's how OIDC works.
When you attempt to log into an application
called the relaying party or RP,
the RP sends an authentication request
to OpenID provider or OP.
The OP authenticates the user and returns an ID token,
which is a JSON Web token, or JWT,
containing user identity information back to the RP.
The RP then validates the ID token
and grants access to the user.
This process allows the users
to authenticate once with the OP and then gain access
to multiple applications without logging in again.
However, this convenience of the OIDC
also introduces potential security risks
that attackers can exploit.
First, let's look at ID token manipulation attacks.
In an ID token manipulation attack,
an attacker modifies the ID token
to gain unauthorized access.
ID tokens are JWTs that contain claims
about the user's identity and privileges.
If the token's signature validation is weak
or improperly implemented,
attackers can alter the token's payload
to escalate privileges or impersonate another user.
For example, a typical ID token
might look something like the following JSON code.
Here we see these tokens are constructed
with three primary fields,
a header, payload, and signature,
which are then encoded to base 64 format.
An attacker might intercept this token,
modified the admin claim from false to true,
and then reign the token
if the RP does not properly validate the signature.
Using tools like Burp Suite,
an attacker could decode, modify, and then encode the token
to manipulate the user roles and gain unauthorized access.
To protect against token ID manipulation,
we can advise our clients
to always validate the token signature
using the OP's public key,
ensure the integrity and confidentiality of the tokens
and also enforce strict validation rules
for the token claims.
Next, let's discuss ID token replay attacks.
In an ID token replay attack,
an attacker intercepts a valid ID token
and reuses it to gain unauthorized access.
This can occur if the relaying party does not properly check
for token reuse or does not set a token expiration time.
For example, an attacker might capture an ID token
during a valid login session using a tool like Wireshark
and replay it to authenticate as the user.
The attacker captures the token
and uses it to make repeated requests to the RP,
gaining unauthorized access
without needing the user's credentials.
To defend against ID token replay attacks,
implement mechanisms to detect and reject replay tokens,
such as using unique identifiers
called nas-is for each token,
ensuring tokens have short lifetimes
and employing mechanisms like token binding.
Next, let's look at an ID token injection attack.
In an ID token injection attack,
an attacker exploits the vulnerabilities
in the application itself that processes the ID tokens.
By injecting malicious tokens,
the attacker can manipulate the authentication process
to gain unauthorized access.
For example, an attacker could exploit
a vulnerable applications code,
which improperly handles user input within a token request.
Suppose the application
constructs an authentication requests like the following.
We see here that the user input variable is not sanitized
and an attacker could just inject a crafted token
to modify the authentication logic.
So again, to defend against ID token injection attacks,
always validate and sanitize user inputs,
use parameterized queries,
and enforce strict validation of JWT tokens.
Another issue with OpenID Connect
is the WebFinger Service.
This service helps find the OpenID provider for a user.
The WebFinger Service is available
at the .well-known/webfinger endpoint
and provides information about users
and resources to the server.
Attackers can misuse this endpoint
to check if a specific user has an account on the server
by making traffic queries like the following,
which has a username of John Snow.
And this request can reveal whether the John Snow user
exists on a server,
potentially disclosing sensitive information.
Now, another more advanced attack
is the server side request forgery
via dynamic client registration.
The OpenID Connect Dynamic Client Registration
lets apps register with the OpenID provider dynamically.
This feature can be misused
for server side request forgery attacks.
By changing certain parameters in the registration request,
the attackers can trick the OpenID provider
into sending ACTP requests into their own servers.
This can make the provider fetch harmful data
and expose sensitive information.
So remember, ID token manipulation attacks
involve modifying ID tokens to escalate privileges,
ID token replay attacks reuse capture tokens
to gain unauthorized access
and ID injection attacks exploit vulnerabilities
in ID token processing.
Additionally, abusing the WebFinger service
and exploiting server side request forgery
via dynamic client registration,
are significant threats in OpenID Connect implementations.
Understanding these methods
will help you both defend against
and use these attacks in penetration tests.