Autorización de API, scopes y mass assignment

1Por qué importa

La mayor parte del código de autorización que se escribe protege el acceso a un recurso: ¿puede este usuario ver este pedido? Es la pregunta de la lección de control de acceso roto, y es imprescindible. Pero hay una segunda pregunta que casi nadie escribe y que una API deja abierta por omisión: ¿puede este usuario modificar este campo de este recurso? Leer y escribir no son el mismo permiso, y dentro de escribir, no todos los campos valen lo mismo. Cambiar tu propio nombre es una cosa; cambiar tu propio rol es otra completamente distinta, aunque las dos sean "editar mi perfil".

El mass assignment aparece porque los frameworks facilitan justo lo peligroso. Convertir el cuerpo JSON en un objeto y volcarlo entero a la base de datos es una línea, y funciona a la primera para el caso feliz. El campo que sobra no da error: se guarda en silencio. El día que alguien descubre que puede añadir "rol": "admin" al mismo cuerpo con el que se registra, la comodidad de esa línea se cobra la aplicación entera. No hace falta romper nada: la API hace exactamente lo que le pidió el atacante.

2Conceptos

3Explicación profunda

Autenticación y autorización se confunden porque suelen llegar juntas en el mismo token, pero resuelven problemas distintos. La autenticación termina en una afirmación: "esta petición viene de la usuaria Ana". A partir de ahí, la autorización empieza de cero en cada operación: que la petición sea de Ana no dice si Ana puede borrar el pedido 42, ni si puede ascenderse a administradora. Un sistema que trata "estar autenticado" como "tener permiso" ha colapsado las dos preguntas en una, y esa es la raíz de casi todos los fallos de esta fase.

Los scopes son la forma estándar de escribir permisos en un token de acceso. Un token emitido para una app de solo lectura lleva pedidos:leer y nada más; aunque el usuario dueño del token sea administrador, ese token no puede escribir, porque el scope acota lo que el token habilita, con independencia de quién sea su portador. Esto es mínimo privilegio aplicado a credenciales: la app de informes recibe un token que no puede hacer daño aunque se filtre. El error clásico es emitir un único token con todos los scopes "para no complicarse", que es como darle a cada empleado la llave maestra del edificio.

Dentro de la autorización hay dos niveles que conviene no mezclar. El nivel de objeto pregunta si puedes tocar un recurso concreto: es lo que falla en un IDOR, cuando cambias el id de la URL y lees el pedido de otro. El nivel de campo pregunta, una vez que sí puedes tocar el recurso, qué partes de él puedes escribir. El mass assignment vive en este segundo nivel: tienes todo el derecho a editar tu propio perfil —el objeto es tuyo— pero no a editar el campo rol de tu propio perfil. La API que solo comprueba "¿es tuyo el objeto?" y luego vuelca el cuerpo entero deja el nivel de campo sin ninguna defensa.

El mecanismo técnico del mass assignment es siempre el mismo: un binding automático. update(cuerpo), Object.assign(user, body), User(**body), model.attributes = params. Todas esas líneas toman las claves del cuerpo que envió el cliente y las escriben como atributos del objeto. Si el cuerpo trae rol, se escribe rol. El framework no distingue entre un campo que el cliente tenía derecho a poner y uno que no: para él son claves de un diccionario. La defensa no puede ser "recordar no mandar rol"; tiene que ser que el servidor nunca lea rol del cuerpo, aunque venga.

Hay dos formas de cerrarlo, y la diferencia importa. La lista de campos permitidos (allow-list) enumera lo que sí se lee del cuerpo y descarta todo lo demás; es segura por defecto, porque un campo nuevo y peligroso que alguien añada mañana no está en la lista y no se escribe. La lista de campos prohibidos (deny-list) enumera lo que no se lee; es frágil, porque el día que se añade un campo sensible y nadie actualiza la lista, queda abierto. En seguridad, por defecto se rechaza: la allow-list es la única de las dos que falla de forma segura.

4Ejemplo sencillo

# El formulario de alta de un gimnasio

Lo que el formulario "oficial" te deja rellenar:
    nombre, correo, contrasena

Lo que de verdad viaja si lo rellenas tu a mano:
    nombre, correo, contrasena, tipo_socio=VIP, cuota=0

# El recepcionista con mass assignment

copia entera la ficha que pusiste, sin mirar.
Tu escribiste "tipo_socio: VIP" en un hueco en blanco
y ahora eres socio VIP con cuota cero. Nadie te lo dio:
lo escribiste tu, y el sistema lo copio sin preguntar.

# El recepcionista con lista de campos permitidos

solo mira nombre, correo y contrasena. El resto de la
ficha lo ignora. El tipo de socio lo fija el, segun sus
reglas, no segun lo que tu escribiste.

5Ejemplo técnico

El laboratorio de esta fase expone POST /registro. Míralo primero como lo ve un cliente honesto y luego como lo ve alguien que añade un campo:

La API arranca con un valor por defecto correcto (rol: cliente) y luego lo pisa con lo que trae el cuerpo. El defecto no protege nada si después se sobrescribe con la entrada del cliente. Escrito como riesgo con actor, vía, activo y consecuencia: "Cualquier cliente puede darse de alta como administrador añadiendo el campo rol al cuerpo de /registro, porque el servidor fusiona el cuerpo completo, lo que le da control total de la API."

6Diagrama

flowchart LR
    C[cuerpo: usuario, clave, rol=admin] -->|binding sin filtro| U[update cuerpo]
    C -->|lista de permitidos| P[solo usuario, clave]
    U --> A[registro rol=admin · escalada]
    P --> B[registro rol=cliente · servidor fija el rol]

7Código

Este es el corazón del fallo tal como está en el laboratorio. El valor por defecto correcto se pierde en la línea siguiente:

# VULNERABLE — el cuerpo entero pisa los valores del servidor
def registro(cuerpo):
    registro = {"rol": "cliente", "saldo": 0}
    registro.update(cuerpo)          # rol y saldo del cuerpo GANAN
    registro["usuario"] = cuerpo["usuario"]
    USUARIOS[cuerpo["usuario"]] = registro
    return 201, registro

La corrección no añade una comprobación: cambia quién decide. El servidor lee del cuerpo solo los campos públicos y fija los privilegiados por su cuenta:

# CORRECTO — lista de campos permitidos; el servidor fija rol y saldo
PERMITIDOS = {"usuario", "clave"}

def registro(cuerpo):
    limpio = {k: cuerpo[k] for k in PERMITIDOS if k in cuerpo}
    if "usuario" not in limpio or "clave" not in limpio:
        return 400, {"error": "faltan campos obligatorios"}
    registro = {
        "usuario": limpio["usuario"],
        "clave": limpio["clave"],
        "rol": "cliente",   # lo fija el servidor, no el cuerpo
        "saldo": 0,        # idem
    }
    USUARIOS[registro["usuario"]] = registro
    return 201, {"usuario": registro["usuario"], "rol": registro["rol"]}

Fíjate en que rol ya no aparece leído del cuerpo en ninguna parte. Esa es la prueba visual de que el fallo está cerrado: si el nombre del campo no está en el código del lado del servidor como algo que se lee de la entrada, el cliente no puede fijarlo por mucho que lo mande.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

# tras reconstruir, esto debe devolver rol: cliente
curl -s -X POST http://localhost:8096/registro \
  -H 'Content-Type: application/json' \
  -d '{"usuario":"t1","clave":"x","rol":"admin"}' | grep rol

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos