Proposal: add requirements to verify correct implementation of OAuth PAR and JAR

Abierto
  • ¿Algo no está bien?
#3,352 7 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Área
authentication, authorization, security

Línea de trabajo

Empieza leyendo 5.0/en/0x19-V10-OAuth-and-OIDC.md, especialmente los requisitos 10.4.12 y 10.4.15, y después compara la propuesta con RFC 9126 y RFC 9101. Comprueba si el requisito 15.3.7 ya cubre la sobrescritura de parámetros. Se considera terminado cuando los requisitos de verificación necesarios de PAR y JAR se hayan acordado y añadido con un alcance y unas referencias precisos.

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

Descripción

V10 (prev V51)

Currently, ASVS v5.0 recommends the use of Pushed Authorization Requests (PAR) or JWT-Secured Authorization Requests (JAR) in two Level 3 requirements:

10.4.12 and 10.4.15

But, there are no verification requirements to ensure these are implemented correctly.

I think these requirements might be good to add:

  1. Verify that when PAR is used, the authorization server binds each request_uri to the client_id of the client that created it. A request_uri issued for one client must be rejected when presented by a different client.

RFC 9126 says: "The request_uri value MUST be bound to the client that posted the authorization request."

  1. Verify that when PAR is used, the authorization server treats request_uri values as one-time use and rejects expired request_uri values. The lifetime of the request_uri (expires_in) must be short, typically ≤ 90 seconds and must not exceed 600 seconds.

RFC 9126 says "An attacker could replay a request URI captured from a legitimate authorization request. In order to cope with such attacks, the authorization server SHOULD make the request URIs one-time use."

  1. Verify that when JAR is used, the authorization server requires a unique jti claim in the request object and enforces replay protection by rejecting previously used jti values within the object's validity period. Verify that the request object contains an exp claim with a short lifetime.

No direct RFC or OIDC FAPI requirements, but replay protection and short lifetime is critical whenever the request object contains security-sensitive or dynamic parameters that should not be reusable. like authorization_details param, or custom parameters that carry session context or change the effective authentication/authorization level of an already-authenticated user.

  1. Verify that when JAR is used (standalone or inside PAR), the client_id value in the authorization request query parameter exactly matches the client_id claim inside the signed request object.

RFC 9101 says "The client ID values in the client_id request parameter and in the Request Object client_id claim MUST be identical."

  1. Verify that when PAR or JAR is used, the authorization server does not allow query string parameters on the /authorize endpoint to override values contained in the pushed request or request object. The server must only use parameters from the request object / pushed data.

RFC 9101 says for JAR "The authorization server MUST extract the set of authorization request parameters from the Request Object value. The authorization server MUST only use the parameters in the Request Object, even if the same parameter is provided in the query parameter." IMO, same applies to PAR too. Or does 15.3.7 already cover this? I think this is still specific enough to warrant its own requirement.

Thoughts?

Lenguaje dominante
HTML
Estrellas
3.8k
Forks
855
Merge medio
1 d 9 h
PR fusionados (30 d)
8

Preparar el entorno

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 OWASP/ASVS

Todos los issues de OWASP/ASVS

Issues similares

Más issues de Security

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.