Token Cross Service Relay Attack

Severity	High
Classifications	CWE-20: Improper Input Validation CWE-287: Improper Authentication
OWASP Category	OWASP API2:2023 Broken Authentication

A vulnerability arises when a JSON Web Token (JWT) is signed by the same service but doesn’t verify the issuer (the source of the token) and/or the audience (the intended recipient). This can lead to security risks, as it means an attacker could create a forged JWT with the same service signature and manipulate the issuer and audience fields. Without proper verification, the service may accept the forged token, potentially granting unauthorized access or compromising the system’s security.

For more details, you can refer to the jwtop documentation on Cross-Service Relay Attack.

Services impacted

Social Identity Providers

Most of the social identity providers generate ID tokens using the same key pair. In addition of JWT integrity verifications, the issuer and audience must be verified to ensure the token has been generated from the expected client.

Here are some social identity providers that are impacted with this vulnerability:

Service	Description	Documentation
Google	Google provides ID tokens generated from the same key pair. The audience must be verified to ensure the token has been generated from the expected Google Project’s Client Id.	Validate Google Id Token
Facebook	Facebook provides ID tokens generated from the same key pair. The audience must be verified to ensure the token has been generated from the expected Facebook App Id.	Validate Facebook Token
Microsoft	Microsoft provides ID tokens generated from the same key pair. The audience must be verified to ensure the token has been generated from the expected Microsoft App Id.	Validate Microsoft Id Tokens
Apple	Apple provides ID tokens generated from the same key pair. The audience must be verified to ensure the token has been generated from the expected Apple App client_id.	Validate Apple Id Tokens

IAM / Authorization Services

Some IAM Services generate JWT tokens using the same key pair. In addition of JWT integrity verifications, some additional checks must be performed to ensure the token has been generated from the expected client / tenant.

Here are some of the services that are impacted:

Service	Description	Documentation
Firebase / Google Identity Platform	Firebase provides ID tokens generated from the same key pair. The issuer and audience must be verified to ensure the token has been generated from the expected Firebase Project.	Firebase Verify Id Token

Example

Here is an example of JWT (ID Token) issued by Google:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

In this example, the aud claim represents the audience, which is the client ID of the Google Project. The service must verify the aud claim to ensure the token has been generated from the expected Google Project’s Client Id.

Let’s say an attacker creates a new project with the same service and generates a token. The attacker can relay the token to the victim’s project and impersonate the user making the victim’s project believe that the user is authenticated.

Here is an example of a forged token:

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819201.apps.googleusercontent.com",
  "aud": "1234987819201.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

Notice that the aud claim has been changed to the attacker’s project Client Id. If the service doesn’t verify the aud claim, it will accept the forged token and believe that the user is authenticated.

How to test?

Create a new project with the same service and generate a token (through a legitimate authentication process). Then, try to relay the token to your original project and see if the service accepts the token or not. If the service accepts the token, then the service is vulnerable to this attack.

This test requires manual steps. VulnAPI does not currently automate this scan. Create a second project with the same identity provider, obtain a valid token for that project, then send it to your original project’s API. If the API accepts the request, it is vulnerable.

What is the impact?

The impact of this vulnerability is that an attacker could create another project with the same service. When user will authenticate with the malicious project, the attacker can relay the token to the victim’s project and impersonate the user making the victim’s project believe that the user is authenticated.

How to remediate?

To remediate this vulnerability, the service must follow tokens provider’s guidelines. Most of the time, the issuer and audience must be verified to ensure the token has been generated from the expected client. The service must keep verifying token integrity and other claims to ensure the token is not tampered with.