Autenticación y autorización: dos preguntas distintas

En el curso Seguridad web con OWASP Top 10 usted conoció las diez categorías de riesgo de un vistazo. En esta serie se detiene en cada una con calma. Empezamos por la número uno: A01, control de acceso roto, que ocurre cuando una aplicación permite que una persona haga algo o vea algo que las reglas del negocio no le permiten.

Dos preguntas distintas

Toda aplicación que maneja datos de personas debe responder dos preguntas en cada petición:

• Autenticación: ¿quién es usted? Se responde con una contraseña, un segundo factor, un certificado o una llave de acceso. El resultado es una identidad: "esta petición viene de Ana".
• Autorización o control de acceso: ¿qué puede hacer esa identidad con este recurso concreto? El resultado es una decisión: permitir o denegar.

La confusión entre ambas es la raíz de casi todos los fallos de esta categoría. Muchas aplicaciones responden muy bien la primera pregunta y se olvidan de la segunda: comprueban que hay una sesión válida y, a partir de ahí, confían en todo lo que el usuario pida.

Piense en el edificio de una empresa en San José. El guarda revisa la cédula de cada visitante y le entrega un gafete: eso es autenticación. Ahora imagine que ese gafete abre todas las puertas, incluidas la oficina de planillas y el cuarto de servidores. El guarda hizo bien su trabajo, pero nadie decidió qué puertas correspondían a cada persona. Eso es un control de acceso roto.

Qué decide la autorización

Una decisión de autorización completa combina tres piezas: el sujeto (quién pide, con su rol y su organización), la acción (leer, crear, modificar, borrar, aprobar, exportar) y el recurso concreto (este pedido, no "los pedidos").

Sujeto:   ana (rol: cliente, tenant: tienda-norte)
Acción:   leer
Recurso:  pedido 1052 (dueño: beto, tenant: tienda-norte)
Decisión: DENEGAR, el pedido no pertenece a ana

Si una pieza falta en la lógica, aparece una grieta. Una regla que solo mira el rol ("los clientes pueden leer pedidos") sin mirar el recurso deja que cualquier cliente lea cualquier pedido.

La decisión se toma siempre en el servidor. Ocultar un botón o validar con JavaScript en el navegador mejora la experiencia, pero no protege nada: cualquier persona puede enviar la petición HTTP directamente.

DELETE /api/pedidos/1052 HTTP/1.1
Host: tienda.ejemplo.cr
Cookie: sesion=4b9e0d7a61c24f3e

Si el servidor lo ejecuta sin preguntar de quién es el pedido, la interfaz cuidada no sirvió de nada.

Breve historia

La idea es antigua. En 1971 Butler Lampson describió la matriz de acceso, una tabla de sujetos por objetos con los permisos en cada celda, y en 1975 Jerome Saltzer y Michael Schroeder publicaron los principios de diseño que todavía se citan: negar por defecto (fail-safe defaults), verificar cada acceso (complete mediation) y dar el mínimo privilegio.

En la web, la fundación OWASP nació en 2001 y publicó su primer Top 10 en 2003. El control de acceso ha estado siempre en la lista, con nombres cambiantes:

Por qué importa en ciberseguridad y en el trabajo

En los datos que OWASP recopiló para 2021, el 94 % de las aplicaciones analizadas tenía alguna forma de control de acceso roto. Además, las herramientas automáticas la detectan mal: un escáner no sabe que el pedido 1052 es de Beto y no de Ana. Por eso la defensa depende de personas. Quien desarrolla escribe la verificación, quien revisa código la busca, quien prueba escribe los casos negativos y el analista del SOC vigila los registros para detectar abusos. Si nadie lo domina, la falla la descubre un tercero.

Dónde aparece

Conceptos clave

Durante el curso usará herramientas de terminal. Sus sintaxis se escriben así: lo que va entre corchetes es opcional, lo que va en MAYÚSCULAS lo reemplaza usted y ... indica que puede repetirse. Si olvida una opción, pida ayuda a la propia herramienta con --help, por ejemplo curl --help o pytest --help.