Fundamentos de Seguridad de Aplicaciones Web Que Todo Negocio Debería Exigir

Los Riesgos Comunes de Seguridad de Aplicaciones Web, en Lenguaje Claro

La mayoría de las brechas no son obra de un adversario genial explotando una falla exótica. Vienen de una breve lista de errores bien entendidos que siguen repitiéndose porque son fáciles de cometer y fáciles de pasar por alto. La comunidad de seguridad mantiene una lista superior informal de estos, y no necesitas la jerga para entenderlos. Si sabes cuáles son, puedes hacer las preguntas correctas y reconocer una respuesta descuidada.

La inyección es la clásica. Ocurre cuando una aplicación toma lo que sea que un usuario escribe y lo entrega directamente a una base de datos o sistema como si fuera un comando confiable. Un visitante escribe algo astutamente mal formado en una caja de búsqueda o campo de inicio de sesión, y en lugar de tratarse como datos, se ejecuta, permitiéndole leer o destruir registros que nunca debería tocar. La autenticación rota es la siguiente: un manejo débil del inicio de sesión que permite a los atacantes adivinar contraseñas, reutilizar las robadas, o secuestrar una sesión iniciada. El control de acceso roto es cuando la aplicación verifica quién eres pero no qué tienes permitido hacer, de modo que un usuario común puede alcanzar una página de administrador o ver los datos de otro cliente simplemente cambiando un número en la barra de direcciones.

La exposición de datos sensibles completa la lista de los principales. Esto es información privada, contraseñas, detalles de pago, registros personales, almacenada o transmitida sin protección adecuada, de modo que cualquiera que la intercepte o entre al lugar equivocado pueda leerla en texto plano. Y debajo de muchas brechas hay un problema más silencioso: las dependencias desactualizadas. Las aplicaciones web modernas se ensamblan a partir de grandes cantidades de código de terceros, y cuando se descubre una vulnerabilidad conocida en uno de esos componentes, cada aplicación que aún ejecuta la versión antigua queda expuesta hasta que se actualiza. Los atacantes escanean internet buscando exactamente estos agujeros sin parchear y públicamente conocidos porque son la forma más fácil de entrar.

• ▸Inyección: la entrada del usuario se ejecuta como un comando en lugar de tratarse como datos planos
• ▸Autenticación rota: el manejo débil del inicio de sesión permite a los atacantes adivinar, reutilizar o secuestrar credenciales y sesiones
• ▸Control de acceso roto: la app verifica quién eres pero no qué tienes permitido hacer
• ▸Exposición de datos sensibles: datos privados almacenados o enviados sin cifrado adecuado
• ▸Dependencias desactualizadas: vulnerabilidades conocidas en componentes de terceros dejadas sin parchear
• ▸Configuración insegura: ajustes por defecto, permisos abiertos, y mensajes de error verbosos dejados en su lugar

El Estándar Mínimo de Seguridad de Aplicaciones Web Que Debes Exigir a Tus Desarrolladores

No se espera que audites código. Pero tienes derecho a fijar un estándar y pedir a tus desarrolladores que confirmen que lo cumplen, de la misma forma en que esperarías que un contratista construya según las normas sin que tú sepas cómo verter unos cimientos. Las protecciones de abajo no son avanzadas ni costosas. Son el mínimo que los equipos competentes tratan como requisito básico, y la ausencia de cualquiera de ellas debería motivar una conversación directa en lugar de un encogimiento de hombros.

Trata esto como una lista de verificación que puedes entregar y pedir a alguien que te explique punto por punto. Un buen desarrollador podrá decir que sí a cada punto y explicar cómo. Respuestas vagas, o tratar estos como extras opcionales para una fase futura, te dicen algo importante sobre cómo se hizo el resto del trabajo. La seguridad no es una funcionalidad que añades después; es una propiedad de cómo se construyó la cosa, y estos puntos son donde vive esa propiedad.

• ▸Usa HTTPS en todas partes para que el tráfico entre los usuarios y la aplicación esté cifrado en tránsito, no solo en la página de inicio de sesión
• ▸Almacena las contraseñas con hash usando un algoritmo fuerte y moderno, nunca en texto plano ni con cifrado reversible
• ▸Ofrece o exige autenticación multifactor, especialmente para administradores y cualquier acceso a datos sensibles
• ▸Aplica el acceso de mínimo privilegio para que cada usuario y componente del sistema pueda alcanzar solo lo que su rol realmente necesita
• ▸Mantén las dependencias y la plataforma subyacente parcheadas en un calendario regular, no solo cuando algo se rompe
• ▸Cifra los datos sensibles en reposo para que una base de datos o respaldo robado no sea legible
• ▸Valida y sanea toda la entrada del usuario en el servidor para que la entrada mal formada no pueda ejecutarse
• ▸Toma respaldos regulares y prueba el proceso de recuperación, para que una brecha o error sea recuperable en lugar de fatal
• ▸Registra eventos de seguridad significativos y conserva los registros, para que puedas detectar y reconstruir un incidente

Cifrado, Contraseñas y Acceso: los Tres Que Más Importan

Si recuerdas solo unas pocas cosas de esta guía, que sean estas tres, porque previenen las fallas más comunes y más dañinas. La primera es el cifrado en todas partes. HTTPS debería cubrir toda la aplicación, no solo la página donde alguien escribe una contraseña, porque cualquier cosa enviada en texto plano puede ser leída por quienquiera que esté posicionado para interceptarla, en un Wi-Fi compartido o en cualquier punto del camino. Los datos sensibles también deberían cifrarse donde se almacenan, de modo que una base de datos copiada o un respaldo extraviado sea un galimatías para quien termine con él en lugar de una hoja de cálculo lista de tus clientes.

La segunda es cómo se manejan las contraseñas. Las aplicaciones bien construidas nunca almacenan la contraseña real. Almacenan una versión con hash, un revoltijo de un solo sentido que permite al sistema verificar un inicio de sesión correcto sin nunca tener la cosa real, de modo que incluso una base de datos robada no entrega a los atacantes las contraseñas de tus usuarios. Combina eso con la autenticación multifactor, que requiere una segunda prueba de identidad más allá de la contraseña, y derrotas el ataque más común: alguien iniciando sesión con una contraseña robada o reutilizada de otro lugar.

La tercera es el control de acceso hecho sobre el principio de mínimo privilegio. Cada usuario, y cada parte del sistema, debería tener exactamente el acceso que su trabajo requiere y nada más. Un empleado que necesita leer pedidos no debería poder eliminar clientes. Un componente que envía correo no debería tener las llaves de toda la base de datos. Esto limita el radio de impacto cuando algo sale mal, y eventualmente algo saldrá mal. El mínimo privilegio es la diferencia entre un incidente contenido a una cuenta y un incidente que se convierte en una emergencia de toda la empresa.

• ▸Cifra en tránsito (HTTPS en todo el sitio) y en reposo (datos almacenados y respaldos), no de forma selectiva
• ▸Almacena solo contraseñas con hash, para que una brecha de la base de datos no exponga las credenciales reales
• ▸Exige autenticación multifactor para derrotar las contraseñas robadas y reutilizadas
• ▸Otorga acceso de mínimo privilegio a cada usuario y componente del sistema para contener cualquier falla individual

Por Qué la Seguridad Es Más Barata Incorporada Que Añadida Después

El momento más barato para hacer segura una aplicación es mientras se está construyendo, y el costo sube abruptamente cuanto más se aplaza. Diseñar para el mínimo privilegio, el cifrado, y el manejo seguro de la entrada desde el principio añade poco a una construcción competente porque esas elecciones dan forma a la estructura del código a medida que se escribe. Adaptarlas después significa deshacer decisiones que ahora están tejidas a través de toda la aplicación, lo cual es lento, costoso y propenso a errores. Peor aún, la versión que corre sin ellas está expuesta todo el tiempo, así que cada día de retraso es un día de riesgo que estás cargando.

Luego está el costo de equivocarse, que empequeñece el costo de hacerlo bien. Una brecha no es un solo rubro. Es respuesta a incidentes, tiempo de inactividad, e ingeniería de emergencia, seguido de la cola más larga de confianza del cliente perdida, atención regulatoria si hubo datos personales involucrados, y la limpieza de lo que sea que el atacante tocó. Para un negocio pequeño o mediano, esa combinación es el tipo de evento que define un año. Incorporar el estándar mínimo desde el principio no es un impuesto al proyecto. Es el seguro más barato disponible, y se paga con un poco de disciplina por adelantado en lugar de una gran cantidad de dinero y reputación después.

Esta es también la razón por la que el momento correcto para hacer estas preguntas es antes de la construcción, no después. Exigir el estándar mínimo como condición del trabajo no cuesta nada y cambia cómo se construye la aplicación. Descubrir su ausencia después del lanzamiento convierte una decisión de diseño en un proyecto de remediación. Los dueños que mejor salen son los que fijaron el estándar temprano e hicieron que cumplirlo fuera parte de lo que estaban pagando.

• ▸Incorpora el mínimo privilegio, el cifrado, y el manejo de entrada durante la construcción, donde son casi gratis
• ▸Trata el periodo antes de que se añada la seguridad como exposición en vivo, no como un elemento inofensivo en la lista de pendientes
• ▸Sopesa el costo modesto de incorporarla contra la respuesta a una brecha, el tiempo de inactividad, y la confianza perdida
• ▸Haz del estándar mínimo de seguridad una condición escrita del trabajo, no un extra que se espera tener
• ▸Haz las preguntas antes de la construcción, cuando las respuestas dan forma al código, no después, cuando significan retrabajo

Qué Pedir y Cómo Verificarlo

Puedes someter una construcción a un estándar sin leer una línea de código, y deberías. Pide a tus desarrolladores que confirmen, por escrito, cuáles de las protecciones mínimas tiene la aplicación y cómo se implementa cada una. El punto no es pillar a nadie en falta. Es hacer de la seguridad una parte explícita y acordada del trabajo en lugar de un supuesto, y crear un registro al que puedas volver si surgen preguntas después.

Más allá de la construcción en sí, dos cosas mantienen una aplicación segura con el tiempo. La primera es mantenerla parcheada: el software del que dependes tendrá vulnerabilidades descubiertas después del lanzamiento, y un calendario de actualización regular es lo que las cierra antes de que alguien las explote. La segunda es tener un plan de recuperación que realmente hayas probado, porque los respaldos que nunca has restaurado son una esperanza, no una salvaguarda. Para trabajo regulado o sensible, pide la misma disciplina que esperarías de cualquier sistema auditable: registros que documenten quién hizo qué, acceso que siga el mínimo privilegio, y la capacidad de demostrar después de los hechos que los controles estaban en su lugar. Esa evidencia es lo que separa una posición defendible de una incómoda cuando algo sale mal.

• ▸Obtén confirmación por escrito de cuáles protecciones mínimas están implementadas y cómo
• ▸Exige un calendario de parcheo regular para las dependencias y la plataforma subyacente
• ▸Confirma que existen respaldos y que el proceso de restauración realmente se ha probado
• ▸Asegura que los eventos relevantes para la seguridad se registren y que los registros se conserven
• ▸Para trabajo regulado, exige evidencia de que el acceso y los controles pueden demostrarse después de los hechos