Los cinco sitios donde se rompe una web

Es el primero de la lista en casi cualquier informe del sector, y el que viviste en la primera sala.

La forma del fallo: el sistema no comprueba, en cada petición, si quien la hace tiene derecho a lo que pide.

Se presenta de tres maneras, y las tres las has visto o rozado:

• Una página accesible sin comprobar nada — /agenda-interna
• Un dato accesible cambiando un número — ?id=5210
• Una acción que solo debería poder hacer un administrador, disponible para cualquiera que sepa la dirección

Y la razón de que sea el número uno no es que sea el más sofisticado. Es lo contrario: es el más aburrido y el que más se olvida. Nadie olvida poner una pantalla de acceso; mucha gente olvida comprobar el permiso en la tercera pantalla del flujo, la que se añadió después.

La forma del fallo: texto que puso un desconocido acaba formando parte de algo que se ejecuta.

Ya tienes la idea del módulo 2 y de la sala anterior. Lo que cambia es dónde acaba ese texto, y cada destino tiene su nombre:

• Acaba en una consulta a la base de datos → inyección SQL
• Acaba en un comando del sistema → inyección de comandos
• Acaba en la página que ve otro usuario → cross-site scripting

Ese tercero merece una parada, porque es el menos intuitivo. Imagina que alguien escribe en un comentario un fragmento de programa en vez de un texto. Si el sitio lo guarda y luego se lo muestra a otros sin tratarlo, ese programa se ejecuta en el navegador de quien lea el comentario. Con sus permisos. Con su sesión.

Y ahí conecta con la sala anterior: eso es una de las formas de robar una cookie de sesión — y por eso existe la marca HttpOnly, que la hace invisible para el código de la página.

El patrón único detrás de las tres:

Todo intérprete que reciba datos y órdenes por el mismo canal se puede confundir. La solución siempre es la misma: separarlos, no filtrarlos.

Configuración insegura. Contraseñas de fábrica, paneles de administración accesibles, mensajes de error con detalle en pantalla, permisos abiertos. No es un fallo de código: es algo que quedó como venía. Ya lo encontraste dos veces — el respaldo con rw- y la carpeta de subidas ejecutable.

Componentes con fallos conocidos. Casi ninguna aplicación se escribe entera: se apoya en decenas de librerías ajenas. Cuando una de ellas tiene un fallo público, todo lo que la usa lo tiene. Por eso la versión es lo primero que se mira, y por eso uptime importaba.

Fallos de autenticación. Contraseñas débiles permitidas, intentos ilimitados, cierre de sesión que no invalida nada, recuperación de contraseña que se puede abusar.

Y ahora la parte que hace útil toda esta lista, porque memorizarla no sirve de nada:

Las cinco familias se detectan con las mismas cuatro preguntas.

1. ¿Quién puede llegar aquí? — control de acceso
2. ¿De dónde viene este dato y dónde acaba? — inyección
3. ¿Esto quedó como venía de fábrica? — configuración
4. ¿Qué versión es esto? — componentes conocidos

Cuatro preguntas, cinco familias, veinte años de fallos. No hay que saberse la lista: hay que acordarse de preguntar.