Add a mechanism to remove token from exception message

[amas]

It’s not easy to handle jose4j exceptions because some of them can contain a signed token (after “->”).

Current options:

• Log the exception as usual: secret leaked in server logs
• Don’t log the exception: useful information for investigation lost

Example from JUnit tests:

17:04:23.220 DEBUG o.j.j.c.SimpleJwtConsumerTestHelp - Expected exception: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Unable to find a suitable verification key for JWS w/ header {"alg":"ES384"} from JWKs [org.jose4j.jwk.EllipticCurveJsonWebKey{kty=EC, x=yd4yK8EJWNY-fyB0veOTNqDt_HqpPa45VTSJjIiI8vM, y=UspqZi9nPaUwBY8kD6MPDHslh5f6UMnAiXsg1l3i6UM, crv=P-256}, org.jose4j.jwk.EllipticCurveJsonWebKey{kty=EC, x=3WPq7AnMkQekA1ogYFqNS5NBOXPs68xadKvtsn4pgas, y=CEvQFmGwKv96TQYRrgS-nFl9xWfN8PuLnIwBVmtpfp0, crv=P-256}, org.jose4j.jwk.EllipticCurveJsonWebKey{kty=EC, x=DUYwuVdWtzfd2nkfQ7YEE_3ORRv3o0PYX39qNGVNlyA, y=qxxvewtvj61pnGDS7hWZ026oZehJxtQO3-9oVa6YdT8, crv=P-256}, org.jose4j.jwk.RsaJsonWebKey{kty=RSA, n=mGOTvaqxy6AlxHXJFqQc5WSfH3Mjso0nlleF4a1ebSMgnqpmK_s6BSP0v9CyKyn_sBNpsH6dlOsks4qwb88SdvoWpMo2ZCIt8YlefirEaT9J8OQycxMvk7U1t6vCyN8Z68FrwhzzsmnNI_GC723OfMhcEZiRGNRJadPCMPfY3q5PgRrCjUS4v2hQjaicDpZETgbGxWNuNiIPk2CGhG3LJIUX4rx5zrFPQuUKH2Z1zH4E39i3Ab0WBATY0warvlImI5_rT-uCvvepnaQ6Mc4ImpS3anLNjfPlaNVajl5aRuzzRO77XePN-XzFJUVbC_v1-s2IcJf8uB-PMKAtRqz_kw, e=AQAB}, org.jose4j.jwk.RsaJsonWebKey{kty=RSA, n=4SoqXJikILVhuwpeOYjbi_KGFXfvMaiBtoDm7nKsVc8ayQ4RBGbQdqHIt6gxSSTHrRSbQ2s5lAHfeyBJ9myQitCwxHFzjIDGcp5_u0wNWJbWUsDnbS-pwAQsZXZ3m6u_aDEC4sCTjOuotzwJniehVAkm2B1OnoYVhooKt9CTjVj1hwMf8Cpr171Vt559LyzUhRml6Se_AJWG_oFLV2c5ALCi2USfq2G_zoXFt9Kc93LJ9XoPy-hbQXA13OXwi9YL_BDLk8nd7QfaUgm77-j6RbOYg0l0PTloggw7km7M1D8iDASfkuII-Dzqedcm3KQb0Quo20HkirlIk67E-jOk6Q, e=AQAB}]): JsonWebSignature{"alg":"ES384"}->eyJhbGciOiJFUzM4NCJ9.eyJzdWIiOiJtZSIsImV4cCI6MTQ5NDQzOTIzMSwiYXVkIjoidGhlIGF1ZGllbmNlIiwiaXNzIjoidGhlIGlzc3VlciJ9.NyRtG_eFmMLQ0XkW5kvdSpzYsm6P5M3U8EBFKIhD-jw8E7FOYw9PZ3_o1PWuLWH3XeArZMW7-bAIVxo2bHqJsSUtB6Tf0NWPtCpUF2c1vbuRXEXkGrCUmc4sKyOBjimC]

‌

‌

Maybe there could be a config option to remove the token from Exceptions? (or at least the signature part)

thanks!

[Brian Campbell]

There’s always some tension between enough useful information and too much information that might have security implications. But for many years now the raw content of a token that’s considered invalid in that context has seemed like it falls into the enough useful information category. And to be honest, I don’t see compelling reason to do otherwise.

[amas]

The payload of a token is usually acceptable in logs I guess, but not a signed token, like probably most other secrets.

https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

The following should usually not be recorded directly in the logs, but instead should be removed, masked, sanitized, hashed, or encrypted:

• Application source code
• Session identification values (consider replacing with a hashed value if needed to track session specific events)
• Access tokens
• …

(I have seen also that reported by security audits.)

[amas]

that’s considered invalid in that context

The fact there is an Exception in the token leak scenario mitigates the problem, but it doesn’t mean the token is fully unusable by an attacker.

For example it can be a transient error, or a token sent to the wrong app, …

[Brian Campbell]

Thank you for your suggestion regarding removing tokens from exception messages. While we understand the security concerns, we believe that providing detailed information, including tokens, is crucial for debugging and resolving issues effectively. The current design prioritizes transparency and ease of troubleshooting. We recommend implementing internal logging policies or custom handlers to sanitize logs as needed. Given our resource constraints and existing priorities, this change isn't a top priority at the moment. We appreciate your understanding and encourage contributions if you have a specific implementation in mind (that are mindful of said resource constraints and existing priorities and existing user base).

[amas]

Thanks for the response.

In prod environments, I don’t think logging token signature is more important than security. (Usually token body is enough.)

Example of CVEs about secret leaking in logs: https://groups.google.com/g/kubernetes-announce/c/ScdmyORnPDk