Security review findings: hardening opportunities

Abierto
  • ¿Algo no está bien?
#723 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
ruby
Área
security

Línea de trabajo

Start by reading the cited locations in lib/jwt/encoded_token.rb, lib/jwt/jwa/, lib/jwt/configuration/decode_configuration.rb, lib/jwt/jwk/key_base.rb, and lib/jwt/claims/. The findings cover distinct behaviors and include suggestions, but do not name tests; look for existing tests for each behavior before deciding scope. Done means the selected findings have clear dispositions and any agreed changes are covered by tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Security Review Findings

Internal security review of ruby-jwt v3.1.3 identified several hardening opportunities. None are assessed as CVE-eligible, but several are worth addressing.

Medium Severity
1. b64: false sets @claims_verified prematurely in EncodedToken

Location: lib/jwt/encoded_token.rb:192-194

When a token has b64: false, decode_payload internally calls verify_claims!(crit: ['b64']), which sets @claims_verified = true after only checking the crit header. If unverified_payload is accessed before payload without an explicit verify_claims! call, the payload accessor's claim verification guard is bypassed.

Conditions: Requires direct EncodedToken API usage + b64: false tokens + accessing unverified_payload before payload without calling verify_claims!. The JWT.decode path is not affected.

Suggestion: Use a private method for the internal crit check that does not set @claims_verified.

2. HMAC nil/empty key accepted silently

Location: lib/jwt/jwa/hmac.rb:24,37

Both sign and verify coerce nil keys to empty strings (signing_key ||= ''). Applications that accidentally pass nil as the HMAC key get tokens signed with zero-entropy keys without any warning.

Suggestion: Raise an error or deprecation warning when the HMAC key is nil or empty.

3. HMAC minimum key length enforcement off by default

Location: lib/jwt/configuration/decode_configuration.rb — enforce_hmac_key_length defaults to false

RFC 7518 Section 3.2 requires HMAC keys to be at least as long as the hash output (32/48/64 bytes for HS256/384/512). The check exists but is disabled by default.

Suggestion: Consider defaulting to true in the next major version.

Low Severity
4. RSA/PS verification lacks key type check

Location: lib/jwt/jwa/rsa.rb:21-25, lib/jwt/jwa/ps.rb:21-24

Unlike HMAC (is_a?(String)) and ECDSA (is_a?(OpenSSL::PKey::EC)), RSA/PS verify methods don't validate the key type. A String key produces NoMethodError instead of a clear VerificationError. Not exploitable (verification fails either way) but inconsistent.

5. No minimum RSA key size on verification

Location: lib/jwt/jwa/rsa.rb:21-25

The 2048-bit minimum is enforced on signing but not on verification. Low practical impact since the application controls verification keys.

6. JWK objects expose private keys via inspect

Location: lib/jwt/jwk/key_base.rb

No inspect override means debug logging of JWK objects could expose private key material from @parameters.

Suggestion: Override inspect to exclude private key components.

7. VerifierContext exception propagation with mixed key types

Location: lib/jwt/jwa/verifier_context.rb:14-18

When a key of the wrong type raises VerificationError inside .any?, the exception propagates without trying remaining keys. Only affects direct EncodedToken API users providing heterogeneous key arrays.

Suggestion: Rescue VerificationError within the .any? block and treat as false.

Informational
8. Issuer validation uses === semantics

Location: lib/jwt/claims/issuer.rb:21-24

The case/when *issuers pattern means Regexp or Proc objects passed as expected issuers silently enable flexible matching rather than strict string equality. Not a vulnerability (application controls the issuer list) but may surprise developers.

9. Claim error messages include expected values

Location: lib/jwt/claims/audience.rb:22, lib/jwt/claims/issuer.rb:25

Error messages include both expected and received claim values. If surfaced to clients or logs, internal service identifiers could be disclosed.

Strong Points

The library handles the major JWT attack vectors well:

  • Algorithm confusion defense via key type checking on HMAC/ECDSA
  • Constant-time HMAC comparison via OpenSSL.fixed_length_secure_compare
  • none algorithm requires explicit opt-in and is blocked via JWK
  • Strict base64 decoding since v3.0.0
  • Algorithm whitelist model (non-empty allowed_algorithms required)
  • No dangerous dynamic dispatch (eval, send, const_get, etc.)
  • RSA 2048-bit minimum on signing
  • JWK cryptographic parameter immutability after initialization
Lenguaje dominante
Ruby
Estrellas
3.7k
Forks
381
Merge medio
17 h 10 min
PR fusionados (30 d)
11

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de jwt/ruby-jwt

Todos los issues de jwt/ruby-jwt

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.