Enhance JWT authorization by validating issuer before fetching public keys

[adamweeks]

🔒 Critical Security Fix: Prevent SSRF Attacks in JWT Validation

Summary

This PR fixes a critical SSRF (Server-Side Request Forgery) vulnerability in the JWT authorization handler that could allow attackers to make the server send HTTP requests to arbitrary URLs.

Problem

The JWTAuthorizationHandler.validateToken() method was calling fetchPublicKeys() with an unvalidated issuer claim extracted from incoming JWT tokens. An attacker could craft a malicious JWT with any issuer URL and force the server to make HTTP requests to:

• Attacker-controlled domains (e.g., https://evil-attacker.com/idb)
• Internal network resources (e.g., http://192.168.1.1/idb, http://localhost:8080/idb)
• Cloud metadata services (e.g., http://169.254.169.254/latest/meta-data)

This could lead to:

• Information disclosure from internal services
• Port scanning of internal networks
• Credential theft from cloud metadata services
• Potential pivot points for further attacks

Solution

Added issuer validation BEFORE any network requests are made:

1. Validate issuer claim exists - Reject tokens with missing or empty iss claim
2. Whitelist validation - Check issuer against LIST_VALID_ISSUERS before fetching keys
3. Early rejection - Throw AccessTokenException immediately for invalid issuers
4. Security logging - Log all invalid issuer attempts for auditing

Changes Made

• Added issuer validation in validateToken() method (lines 56-66)
• Removed unused DEFAULT_IDENTITY_BROKER_URL constant
• Simplified fetchPublicKeys() URL construction (issuer now guaranteed to be valid)
• Improved exception handling to preserve security error messages

Files Changed:

• src/main/java/com/cisco/wccai/grpc/server/interceptors/JWTAuthorizationHandler.java

Attack Vectors Prevented

✅ External attacker domains
✅ Internal network scanning (localhost, private IPs)
✅ Cloud metadata service access (AWS, GCP, Azure)
✅ Domain hijacking attempts (idbrokerbts.webex.com.evil.com)
✅ URL parsing bypasses (webex.com@evil.com)
✅ Protocol downgrade attacks (HTTP instead of HTTPS)

Backward Compatibility

✅ 100% backward compatible - All legitimate Webex JWT tokens continue to work
✅ Only rejects tokens with invalid issuers (which should never occur in legitimate traffic)

Valid Issuers (Unchanged)

The following Webex issuers remain valid:

• https://idbrokerbts.webex.com/idb
• https://idbrokerbts-eu.webex.com/idb
• https://idbroker.webex.com/idb
• https://idbroker-eu.webex.com/idb
• https://idbroker-b-us.webex.com/idb
• https://idbroker-ca.webex.com/idb

References

• Related Python fix: feat: add JWT authentication for gRPC requests webex/webex-byova-gateway-python#18 (comment)
• OWASP SSRF Guide: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
• CWE-918: Server-Side Request Forgery (SSRF)

Deployment Notes

• Risk Level: Low (backward compatible, security hardening only)
• Monitoring: Watch for "Invalid issuer" log messages post-deployment
• Rollback: Safe to rollback if issues arise, but should not be necessary

---

Severity: 🔴 Critical
Type: Security Fix
Breaking Changes: None