Seis preguntas que hacer sobre la seguridad de su aplicación Laravel

La mayor parte de lo que se escribe sobre seguridad de aplicaciones va dirigido a quienes escriben el código. Si es dueño de una aplicación Laravel y paga a otro para que la cuide, eso no le ayuda mucho. Sigue necesitando saber si la están cuidando.

Estas son seis preguntas con respuestas factuales. No necesita entender las respuestas técnicamente; necesita oír una respuesta concreta, porque el modo de fallo que más vemos no es una medida mal hecha. Es una medida a la que nadie ha llegado todavía, y la vaguedad es a lo que suena eso.

Cada una de ellas es algo que hacemos en nuestros propios sistemas, así que nada de esto es un estándar que nadie cumple.

1. ¿Basta una contraseña para entrar en el admin?

Si la respuesta es sí, eso es lo primero que hay que arreglar. Un panel de admin que solo pide una contraseña está a una contraseña filtrada, reutilizada o adivinada de quedar abierto, y las contraseñas se filtran constantemente por brechas en servicios que no tienen nada que ver.

Una buena respuesta: la verificación en dos pasos es obligatoria, no opcional. Hay una diferencia: opcional significa disponible para quien se moleste.

A qué estar atento: «la tenemos disponible» o «las contraseñas son fuertes». Ninguna de las dos responde a la pregunta.

Pregunte esto junto con lo anterior: ¿cuántas personas pueden iniciar sesión, y esa lista coincide con quien trabaja ahí ahora? Las cuentas antiguas de personas que se fueron son una de las formas de entrar más habituales, y eliminarlas no cuesta nada.

2. ¿Hay algo que lea los logs de verdad?

Casi todas las aplicaciones Laravel registran los inicios de sesión fallidos en algún sitio. Muchas menos tienen algo que mire lo que se registró.

Este es el hueco que señalaríamos primero en la mayoría de las aplicaciones, porque desde fuera parece resuelto. Un intento de adivinar contraseñas contra su panel de admin quedaría anotado fielmente, en orden, con marcas de tiempo, y nadie lo vería, lo que le deja exactamente en la posición de no haberlo registrado.

Una buena respuesta: alguien o algo recibe un mensaje cuando el patrón tiene mala pinta, y hay un ejemplo real de que haya ocurrido.

Dos cosas separan una alerta a la que la gente responde de una que aprende a ignorar. Repítalas si la respuesta que recibe es vaga. Un inicio de sesión correcto por sí solo nunca debería enviar una alerta: eso es usted o su desarrollador llegando a trabajar, y un correo diario entrena a todo el mundo para ignorar el canal. Pero un inicio de sesión correcto en la misma ventana que una serie de fallos siempre debería alertar, porque esa es la forma de alguien entrando. Y un ataque sostenido tiene que producir un mensaje, no uno por comprobación, o el aviso queda enterrado bajo su propio volumen y su proveedor de correo empieza a bloquear al remitente.

3. Si el servidor desapareciera esta noche, ¿desde dónde restauraría?

No «¿tiene copias de seguridad?». Pregunte dónde están, cuándo se hizo la última y si alguien ha restaurado alguna vez una.

Una buena respuesta: existe una copia en algún sitio distinto del servidor del que salió, hecha en el último día más o menos, y alguien la ha restaurado de verdad y ha mirado el resultado.

Tres detalles en los que insistir, porque aquí es donde las respuestas seguras se equivocan más a menudo:

• Fuera de la máquina. Una copia en el mismo servidor le protege de un mal deploy y de nada más. El día en que lo perdido es el servidor es el día para el que existen estas copias.
• Cifrada antes de salir. Su base de datos guarda nombres, direcciones de correo, mensajes y probablemente direcciones IP. El correo no está cifrado de extremo a extremo, así que un archivo de base de datos sin cifrar adjunto a un correo son datos de clientes en al menos dos buzones. Las nuestras se cifran antes de que nada salga de la máquina, y la copia sin cifrar se queda atrás.
• La clave no está solo en el servidor. Una clave de cifrado guardada únicamente en el archivo de configuración de la aplicación no protege nada una vez que lo perdido es el servidor. Tiene que estar también en un gestor de contraseñas.

A qué estar atento: «está todo respaldado automáticamente». ¿Por qué, hacia dónde y cuándo miró alguien por última vez?

Una copia que nadie ha restaurado no es una copia de seguridad. Es un archivo con un nombre tranquilizador. La única forma de saberlo es restaurar una en un sitio seguro y leer unas cuantas filas de ella, que es una prueba que puede hacer una vez al año y dormir mejor por ello.

4. ¿Qué pasa si alguien envía el formulario de contacto diez mil veces?

Todo formulario público de su sitio escribe en su base de datos y normalmente envía al menos un correo. Sin un límite, una tarde de envíos automatizados llena sus tablas, entierra cualquier consulta real que llegara ese día y hace que su dominio de envío quede marcado como fuente de spam. Esto último puede tardar semanas en deshacerse y afecta a cada correo que envía su negocio, incluidas las facturas.

Una buena respuesta: cada formulario público tiene un límite, y es bajo. Los nuestros permiten un puñado por minuto desde el mismo origen: mucho más de lo que cualquier persona rellena un formulario, mucho menos de lo que hace que inundar merezca la pena.

Un detalle que indica que alguien lo pensó: lo que ve un visitante bloqueado. Una persona que hizo doble clic debería recuperar el formulario con una frase que lo explique, no una página de error pelada con la que no puede hacer nada.

5. ¿Qué se le está diciendo al navegador?

Un puñado de cabeceras HTTP indican al navegador que rechace cosas que de otro modo permitiría: enmarcar su sitio dentro del de otro, adivinar tipos de archivo, filtrar sus URLs internas a los sitios a los que enlaza.

La mayoría llevan cinco minutos. La que lleva trabajo de verdad es la Content Security Policy, que restringe desde dónde puede la página cargar código y adónde puede enviar datos. Es la medida que limita el daño cuando algo sí llega a inyectarse.

Una buena respuesta: están puestas, y alguien puede decirle qué permite la política y por qué.

Cuando lo hicimos en nuestro propio sitio, los informes encontraron algo que no sabíamos: una página de admin enviaba las iniciales del usuario con sesión iniciada a un servicio de terceros en cada carga, por un valor por defecto del framework que nadie había elegido. Ese es el tipo de cosa que esto encuentra.

Relacionado, y pregúntelo directamente: ¿el área de admin renderiza algo que escribió el público? Mensajes del formulario de contacto, URLs enviadas, nombres de archivos subidos. Eso lo lee alguien con sesión iniciada y todos los permisos, lo que lo convierte en el texto más sensible de la aplicación.

6. ¿Cuánto tiempo conserva datos que no necesita?

Las aplicaciones recogen más de lo que pedía el formulario. Direcciones IP, cadenas del navegador y URLs de referencia se guardan junto a los envíos casi por defecto.

Hay razones para conservarlo brevemente; sobre todo, comprobar si una ráfaga de envíos vino de un mismo sitio. Rara vez hay una razón para conservarlo durante años. Los datos que no tiene no pueden filtrarse, no pueden ser requeridos judicialmente y no aparecen en una notificación de brecha.

Una buena respuesta: hay un calendario, corre automáticamente y alguien puede decir qué elimina y al cabo de cuánto tiempo. El nuestro borra los detalles de red de las consultas antiguas conservando la consulta en sí.

Lo que suman las respuestas

Ninguna de estas es exótica y ninguna es cara. Lo que miden es si alguien ha dedicado una tarde a las partes de su aplicación que no producen funcionalidades.

Si obtiene seis respuestas concretas, su aplicación está en mejor forma que la mayoría. Si obtiene seis tranquilizadoras sin detalle detrás, ha aprendido algo útil, y tiene arreglo: en una aplicación típica son unos días de trabajo, no una reconstrucción.

Hacemos este tipo de revisión en aplicaciones Laravel y en las aplicaciones web que crecieron a partir de ellas, incluidas aquellas cuyo desarrollador original hace tiempo que se fue. Si quiere que alguien responda a estas seis sobre su propio sistema, cuéntenos qué está ejecutando.