Lee lo que contesta el servidor

Abre el laboratorio y lanza otra vez el escáner:

dirb http://clinica-meridiano.local

La primera vez esto era magia: escribías un comando y salían rutas. Ahora sabes qué pasó por debajo, y conviene decirlo entero porque es la web resumida:

1. El nombre se tradujo a una dirección — DNS
2. Se abrió una conexión al puerto 80 — saludo de tres pasos
3. Por cada palabra de la lista se mandó un GET /palabra
4. El servidor contestó un código por cada uno
5. El escáner se quedó con los que no eran 404

Nada de eso es magia. Es una conversación repetida cuatro mil veces, y el escáner solo automatiza lo que tú podrías hacer a mano escribiendo direcciones en la barra.

Y ahí está lo que hace útil este módulo: entender la conversación es lo que te permite hacer preguntas que ninguna herramienta hace por ti.

Cada código de respuesta es información, y algunos dicen más de lo que quien los configuró pretendía.

Fíjate en la diferencia entre estos dos casos, porque es sutil y decide cosas:

Una ruta que no existe → 404. «Eso no está aquí.»

Una ruta que existe pero no es para ti → 403. «Está, pero no.»

Un 403 confirma que la página existe. Y eso, a veces, es información que no querías dar: si /panel-admin responde 403 y /panel-xyz responde 404, acabas de decirle a quien pregunta que el panel se llama panel-admin.

Por eso hay sitios que responden 404 a todo lo que no puedes ver, aunque exista. Se llama esconder la existencia, y es una decisión legítima siempre que no sea la única defensa — que es justo el error de la clínica: allí no había ni 403 ni 404, había un 200.

Prueba en el navegador del laboratorio una ruta que no existe, como /admin, y mira qué contesta. Después abre /agenda-interna.

Ese contraste es el incidente entero en dos peticiones.

Los códigos van por centenas, y saber la centena basta para orientarse:

La última fila es la que menos se explica y la más valiosa.

Un 500 significa que el servidor intentó hacer algo y se rompió. Y un servidor que se rompe suele contar por qué: el mensaje de error puede traer la ruta del archivo, el nombre de la base de datos, un trozo de consulta, la versión del programa.

Nada de eso es un fallo de seguridad por sí solo. Todo eso es material para quien busca uno.

Y de ahí sale una recomendación que verás en cualquier revisión: los errores detallados van al registro, no a la pantalla. El usuario ve «algo salió mal»; el equipo ve el detalle completo en un archivo que solo ellos leen.

Es la misma idea de siempre, aplicada a los errores: dar la información justa para lo que hace falta, y ni un dato más.