提出 #866093: lmammino oidc-authorizer 0.4.0 Exposure of Sensitive Information Through Metadata

Sensitive bearer token leakage in oidc-authorizer logs and full JWT claims propagation in authorizer context
Affected package:oidc-authorizer
Affected components:src/handler.rs src/models.rs

Summary:
oidc-authorizer version 0.4.0 exposes sensitive authentication data in two ways.

First, on failure paths, the Lambda authorizer logs raw Authorization header values or full bearer tokens/JWTs to CloudWatch Logs. This can expose credentials to anyone with access to Lambda logs, log exports, or downstream log aggregation.

Second, on successful authentication, the authorizer serializes the full JWT claims set into context.jwtClaims and propagates it to downstream API Gateway integrations. This can unnecessarily expose identity metadata such as email addresses, subject identifiers, issuer, audience, token identifiers, and session-related claims to downstream services and logs.

If a valid bearer token is logged before expiration, a party with log access may be able to replay the token until it expires, depending on the token type, audience, issuer, and downstream validation controls.

Technical details:
The issue is visible in the current code paths.

Failure path logging in src/handler.rs:
- Logs raw header value on token extraction failure:
Failed to extract token from header (header_value='{}')

- Logs full token on token parsing or validation failure:
Failed to parse token header (token='{}')
Failed to validate token (token='{}')

Success path propagation in src/models.rs:
- Serializes the full JWT claims payload into:
context["jwtClaims"] = serde_json::to_string(token_claims).unwrap()

This means malformed or invalid requests can cause sensitive token material to be written to CloudWatch Logs, while successful requests can propagate the entire claims payload to downstream integrations rather than only the minimum required identity fields.

Relevant source locations:
src/handler.rs
src/models.rs

Observed vulnerable behavior:
1. Raw Authorization header leakage:
When the authorizer receives an invalid header format such as:

{
"type": "TOKEN",
"authorizationToken": "NotBearer demo-token",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:example/prod/GET/test"
}

CloudWatch Logs contain the raw header value:

Failed to extract token from header (header_value='NotBearer demo-token')

2. Full bearer token leakage:
When the authorizer receives a malformed or invalid JWT such as:

{
"type": "TOKEN",
"authorizationToken": "Bearer <invalid_or_tampered_jwt>",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:example/prod/GET/test"
}

CloudWatch Logs contain the full token value in failure messages such as:

Failed to validate token (token='...')

3. Full JWT claims propagation:
When the authorizer receives a valid token, the successful response includes context.jwtClaims containing the full serialized claims object.

Example fields propagated downstream may include:
- at_hash
- aud
- auth_time
- username
- email
- exp
- iat
- iss
- jti
- origin_jti
- sub
- token_use

This confirms that the authorizer forwards the full claims payload rather than a minimal required subset.

Steps to reproduce:
1. Deploy oidc-authorizer version 0.4.0 as an AWS Lambda authorizer.

2. Configure it with a valid OIDC provider, such as an Amazon Cognito User Pool.

3. Invoke the authorizer with an invalid non-Bearer authorizationToken:

{
"type": "TOKEN",
"authorizationToken": "NotBearer demo-token",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:example/prod/GET/test"
}

4. Check CloudWatch Logs and confirm that the raw header value is logged.

5. Invoke the authorizer with a malformed or invalid bearer token:

{
"type": "TOKEN",
"authorizationToken": "Bearer <invalid_or_tampered_jwt>",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:example/prod/GET/test"
}

6. Check CloudWatch Logs and confirm that the full bearer token/JWT is logged.

7. Obtain a valid OIDC token from the configured provider.

8. Invoke the authorizer with:

{
"type": "TOKEN",
"authorizationToken": "Bearer <valid_token>",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:example/prod/GET/test"
}

9. Observe the successful authorizer response and confirm that context.jwtClaims contains the full serialized JWT claims payload.

Expected result:
The authorizer should not log raw Authorization headers or full bearer tokens. Logs should use redacted values or non-sensitive correlation identifiers.

The authorizer should not propagate the full JWT claims set by default. It should forward only the minimum claims required by downstream integrations, or make full-claims forwarding an explicit opt-in feature.

Actual result:
The authorizer logs raw header values and bearer tokens on failure paths, and propagates the full JWT claims object on success paths.

Impact:
This is a sensitive data exposure vulnerability.

Potential impact includes:
- Exposure of raw Authorization headers in CloudWatch Logs
- Exposure of full bearer tokens/JWTs in CloudWatch Logs
- Token replay risk if valid tokens are logged before expiration
- Exposure of user identity metadata to operators with log access
- Propagation of full JWT claims to downstream integrations
- Increased blast radius if downstream systems log authorizer context
- Disclosure of email addresses, user identifiers, issuer, audience, token identifiers, and session-related metadata

The issue does not directly provide code execution or privilege escalation. However, leaked bearer tokens may be usable for impersonation until expiration if accepted by downstream services.

Rationale:
An attacker can trigger failure-path logging over the network without authentication by sending crafted Authorization values to an API protected by this authorizer. The primary impact is confidentiality. If valid tokens are logged through operational or validation failure paths, anyone with log access may recover sensitive credentials. Full claims propagation also expands exposure of identity data beyond the authorizer boundary.

Recommended remediation:
- Stop logging raw Authorization headers.
- Stop logging full bearer tokens or JWTs.
- Redact tokens in logs, for example by logging only a fixed message or a short hash of the token.
- Avoid including sensitive token material in error messages.
- Forward only minimum required claims in the authorizer context.
- Make full JWT claims forwarding opt-in and document the privacy/security implications.
- Consider allowlisting specific claims that may be safely propagated.
- Add tests to ensure tokens and raw Authorization headers are never logged.
- Add tests to ensure default authorizer context does not include full JWT claims.

Disclosure status:
A private GitHub Security Advisory already exists for this issue:
GHSA-7pjp-x74w-w983

No CVE has been assigned at the time of this submission. The advisory has been pending maintainer action for approximately one month. This CVE request is submitted with the intent to avoid duplicate assignment and to coordinate tracking of the affected public package version.

• ソース: ⚠️ https://github.com/lmammino/oidc-authorizer
• ユーザー: changli (UID 99220)
• 送信: 2026年06月23日 10:18 (2 月 ago)
• モデレーション: 2026年08月08日 22:18 (2 months later)
• ステータス: 承諾済み
• VulDBエントリ: 387217 [lmammino oidc-authorizer 迄 0.4.0 Fixed Message src/handler.rs unwrap jwtClaims 特権昇格]
• ポイント: 20