1. Introducción a la seguridad en aplicaciones web y superficie de ataque

1.1 Introducción

Hoy casi toda organización depende de aplicaciones web. Sistemas de ventas, banca en línea, paneles administrativos, plataformas educativas, redes sociales, tiendas virtuales, intranets, portales de clientes y APIs consumidas por aplicaciones móviles comparten una característica: exponen funcionalidad a través del navegador o de peticiones HTTP.

Esa capacidad de llegar a usuarios desde cualquier lugar también amplía el riesgo. Una aplicación web recibe entradas continuas desde formularios, URLs, encabezados, cookies, archivos, parámetros JSON y llamadas de terceros. Cada dato recibido puede ser útil para el negocio o convertirse en una oportunidad de ataque si no se procesa correctamente.

La seguridad en aplicaciones web se ocupa precisamente de eso: evitar que un usuario o sistema pueda hacer algo distinto de lo permitido, acceder a datos que no le corresponden, alterar el comportamiento esperado, ejecutar instrucciones maliciosas o afectar la disponibilidad del servicio.

1.2 Qué es una aplicación web desde la perspectiva de seguridad

Desde un punto de vista funcional, una aplicación web es un software accesible a través de HTTP o HTTPS, con una interfaz de usuario o una API que permite consultar, modificar o procesar información. Desde un punto de vista de seguridad, es una combinación de componentes que deben operar bajo control.

Entre esos componentes se encuentran:

• El navegador o cliente que envía solicitudes.
• El frontend que presenta la interfaz y ejecuta código en el navegador.
• El backend que procesa reglas de negocio y toma decisiones.
• La base de datos que almacena información crítica.
• Los servicios externos, APIs y sistemas de autenticación integrados.
• La infraestructura que publica la aplicación: servidor web, balanceador, CDN, contenedores o servicios cloud.

1.3 Qué busca proteger la seguridad en aplicaciones web

Cuando se habla de proteger una aplicación web, no solo se protege código. También se protegen activos de negocio, confianza de usuarios y procesos operativos.

1.4 Por qué las aplicaciones web son un objetivo tan frecuente

Las aplicaciones web están expuestas, procesan datos valiosos y suelen cambiar con rapidez. Eso las vuelve atractivas para atacantes y difíciles de proteger si el desarrollo no incorpora seguridad desde el inicio.

Existen varias razones por las que son un objetivo recurrente:

• Son accesibles remotamente, muchas veces desde internet pública.
• Reciben entradas de usuarios no confiables en casi todos sus flujos.
• Acumulan información sensible y privilegios operativos.
• Integran múltiples tecnologías, bibliotecas y servicios de terceros.
• Cambian constantemente por nuevas funcionalidades, correcciones y despliegues.
• Errores pequeños en código o configuración pueden tener impacto amplio.

Además, la mayoría de los incidentes web no requieren técnicas exóticas. Frecuentemente aprovechan fallas conocidas: validaciones débiles, controles de acceso incompletos, sesiones mal gestionadas o configuraciones inseguras.

1.5 Objetivos de protección

Los objetivos de seguridad sirven para definir qué debe preservarse en una aplicación web y qué controles conviene implementar.

• Confidencialidad: evitar que datos sensibles sean vistos por personas o sistemas no autorizados.
• Integridad: impedir modificaciones indebidas en datos, transacciones o reglas de negocio.
• Disponibilidad: asegurar que la aplicación y sus servicios sigan accesibles cuando se los necesita.
• Autenticidad: verificar correctamente la identidad de usuarios, sistemas y componentes.
• Autorización: garantizar que cada actor solo pueda realizar acciones permitidas.
• Trazabilidad: registrar eventos relevantes para auditar, investigar y responder incidentes.
• Privacidad: tratar datos personales conforme a su sensibilidad y al propósito declarado.

En una aplicación real estos objetivos conviven. Un sistema de pagos, por ejemplo, necesita confidencialidad de los datos, integridad de las operaciones, disponibilidad continua y trazabilidad suficiente para investigar errores o fraudes.

1.6 Diferencia entre una aplicación funcional y una aplicación segura

Una aplicación funcional hace lo que el usuario espera en condiciones normales. Una aplicación segura también se comporta correctamente en condiciones adversas: entradas maliciosas, usuarios curiosos, abuso intencional, errores de configuración, automatización hostil o integración defectuosa.

Una aplicación puede verse bien y cumplir su objetivo de negocio, pero seguir siendo insegura si presenta alguno de estos problemas:

• Acepta datos sin validarlos ni restringir formato, tamaño o contexto.
• Permite cambiar identificadores en la URL y acceder a recursos ajenos.
• Guarda contraseñas de forma débil o expone tokens en lugares inseguros.
• Confía en datos del cliente como si fueran decisiones seguras.
• No diferencia adecuadamente permisos de usuarios comunes y administradores.
• No registra eventos clave o los registra sin contexto útil.
• Expone errores internos, trazas o detalles de infraestructura.

1.7 Superficie de ataque: concepto central

La superficie de ataque es el conjunto de puntos por los que una aplicación puede ser observada, utilizada o abusada. Todo punto de entrada, toda función expuesta y toda dependencia accesible forman parte de esa superficie.

En aplicaciones web, la superficie de ataque suele incluir:

• Formularios de inicio de sesión, registro y recuperación de contraseña.
• Parámetros en URLs, búsquedas, filtros y paginación.
• Cookies, cabeceras HTTP y almacenamiento del navegador.
• Subida y descarga de archivos.
• Endpoints de APIs REST o GraphQL.
• Paneles administrativos y funciones ocultas pero accesibles.
• Integraciones con correo, pagos, almacenamiento o autenticación externa.
• Mensajes de error, logs expuestos y configuraciones por defecto.

Reducir la superficie de ataque no significa quitar valor al producto, sino exponer solo lo necesario y controlarlo adecuadamente.

1.8 Cómo pensar la superficie de ataque paso a paso

Un error frecuente es analizar solo la página visible. La superficie real de una aplicación suele ser mucho mayor. Para entenderla conviene hacer preguntas simples y concretas:

1. ¿Qué entradas recibe la aplicación y desde dónde?
2. ¿Qué datos procesa y cuál es su sensibilidad?
3. ¿Qué decisiones de negocio toma el sistema?
4. ¿Qué roles existen y qué puede hacer cada uno?
5. ¿Qué componentes externos participan?
6. ¿Qué sucede si un usuario manipula cada dato recibido?
7. ¿Qué sucede si un actor automatiza miles de solicitudes?
8. ¿Qué pasa si una dependencia devuelve resultados inesperados?

Estas preguntas ayudan a pasar de una visión superficial a una visión de riesgo real.

1.9 Ejemplo práctico de superficie de ataque

Supongamos una tienda en línea con registro, carrito, pagos, historial de compras y panel administrativo. Su superficie de ataque no es solo la página principal.

1.10 Amenazas comunes en aplicaciones web

Las amenazas web más relevantes no surgen al azar. Se repiten porque muchas aplicaciones comparten los mismos errores de diseño e implementación.

• Inyecciones: la aplicación mezcla datos del usuario con consultas o comandos.
• XSS: se ejecuta código inyectado en el navegador de otros usuarios.
• CSRF: se induce a un usuario autenticado a ejecutar acciones sin intención.
• Control de acceso roto: un usuario accede a funciones o datos que no le corresponden.
• Autenticación débil: credenciales mal protegidas, flujos inseguros o sesiones vulnerables.
• Configuración insegura: errores por defaults peligrosos, cabeceras ausentes o paneles expuestos.
• Uso de componentes vulnerables: bibliotecas o frameworks con fallas conocidas.
• Fallas de lógica de negocio: el sistema permite abusos aunque técnicamente no haya una inyección.

Durante el curso iremos profundizando cada una de estas categorías, pero desde el principio conviene entender que el problema no es solo técnico. Muchas vulnerabilidades aparecen porque la aplicación confía demasiado en el cliente o modela mal sus reglas de negocio.

1.11 OWASP como referencia práctica

En seguridad de aplicaciones web, OWASP es una referencia ampliamente utilizada. No es una herramienta ni un estándar obligatorio, sino una comunidad y un conjunto de guías prácticas que ayudan a identificar, priorizar y mitigar riesgos frecuentes.

Uno de sus aportes más conocidos es el OWASP Top 10, una lista de categorías de riesgos comunes en aplicaciones web. Su valor no está en memorizarla como un listado, sino en usarla como mapa para revisar si una aplicación está expuesta a fallas típicas de autenticación, autorización, validación, configuración o monitoreo.

1.12 Principios fundamentales de diseño seguro

Antes de estudiar vulnerabilidades puntuales conviene fijar principios generales. Son ideas que orientan decisiones de arquitectura, programación y operación.

• No confiar en la entrada: todo dato recibido debe considerarse no confiable hasta ser validado.
• Validar por contexto: no basta con "limpiar" datos; hay que tratarlos según el uso exacto que tendrán.
• Mínimo privilegio: usuarios, servicios y procesos deben tener solo los permisos estrictamente necesarios.
• Defensa en profundidad: se combinan capas de protección para no depender de un único control.
• Denegar por defecto: lo no permitido explícitamente debería quedar bloqueado.
• Seguridad por diseño: los controles se piensan al modelar la solución, no solo al final.
• Fallar de forma segura: ante un error, la aplicación no debe quedar más expuesta ni filtrar información sensible.
• Reducir exposición: menos funcionalidades innecesarias, menos endpoints y menos datos visibles implican menos riesgo.

1.13 El rol de la validación y el control del lado servidor

Muchos desarrolladores comienzan validando formularios en JavaScript para mejorar la experiencia del usuario. Eso está bien, pero no resuelve la seguridad. El navegador está del lado del usuario y puede ser manipulado. Un atacante puede alterar peticiones, omitir validaciones visuales, modificar cookies o llamar directamente a la API.

Por eso, las decisiones de seguridad reales deben tomarse en el servidor. El backend debe validar tipos, formatos, longitudes, rangos, permisos y estado del flujo. También debe decidir si el usuario autenticado puede ejecutar esa operación concreta sobre ese recurso concreto.

Una regla simple ayuda mucho: lo que se valida solo en el cliente mejora usabilidad; lo que se valida en el servidor protege la aplicación.

1.14 Datos, identidad y lógica de negocio

La mayoría de las aplicaciones web gira alrededor de tres ejes: datos, identidad y acciones. Si cualquiera de ellos se gestiona mal, la seguridad se degrada.

• Datos: qué información se recibe, se guarda, se muestra y se comparte.
• Identidad: cómo se sabe quién es el usuario o servicio que interactúa.
• Acciones: qué puede hacer cada actor sobre cada recurso.

La seguridad aparece cuando el sistema mantiene control sobre esos tres ejes. Un sitio puede autenticar bien, pero fallar en autorización. Puede restringir funciones, pero exponer datos en respuestas excesivas. Puede almacenar datos correctamente, pero permitir operaciones no previstas por un error de lógica.

1.15 El impacto real de una vulnerabilidad

No todas las vulnerabilidades generan el mismo daño, pero incluso fallas aparentemente pequeñas pueden producir consecuencias graves según el contexto.

1.16 Seguridad durante todo el ciclo de vida

Una aplicación no se vuelve segura por una única auditoría ni por agregar una cabecera HTTP. La seguridad debe acompañar todo el ciclo de vida del software.

1. En el análisis, se identifican datos sensibles, amenazas y requisitos de seguridad.
2. En el diseño, se definen roles, flujos, dependencias y controles.
3. En el desarrollo, se aplican prácticas seguras y validaciones consistentes.
4. En las pruebas, se revisan errores funcionales y también abusos posibles.
5. En el despliegue, se asegura la configuración del entorno.
6. En la operación, se monitorean eventos, se corrigen vulnerabilidades y se gestionan cambios.

Cuanto más tarde se descubre un problema de seguridad, más costoso suele ser corregirlo.

1.17 Errores de enfoque muy comunes

• Creer que HTTPS por sí solo vuelve segura a la aplicación.
• Confiar en que el framework resuelve automáticamente todos los riesgos.
• Proteger formularios visibles pero olvidar APIs o endpoints internos.
• Asumir que un usuario autenticado ya es un usuario autorizado para todo.
• Validar solo en el frontend.
• Mostrar mensajes de error demasiado detallados.
• Conservar funciones antiguas, rutas de prueba o cuentas por defecto.
• No revisar dependencias y bibliotecas de terceros.

1.18 Roles involucrados en la seguridad de una aplicación web

La seguridad no depende exclusivamente del programador. Intervienen distintos perfiles y cada uno influye en el resultado final.

• Analistas funcionales: ayudan a identificar procesos sensibles y casos de abuso.
• Desarrolladores frontend: deben evitar exposiciones innecesarias y manejar correctamente datos y sesiones del lado cliente.
• Desarrolladores backend: implementan validación, autorización, persistencia y reglas de negocio seguras.
• Administradores o DevOps: aseguran despliegue, secretos, permisos, actualizaciones y hardening del entorno.
• Especialistas de seguridad: revisan riesgos, prueban controles y responden incidentes.
• Responsables del negocio: definen criticidad, impacto aceptable y prioridades de protección.

1.19 Caso conceptual: portal de alumnos

Imaginemos un portal universitario donde los alumnos inician sesión, consultan notas, descargan comprobantes, actualizan datos personales y se inscriben a materias. A simple vista parece una aplicación administrativa sencilla. Sin embargo, la seguridad debe responder preguntas concretas:

• ¿Cómo se evita que un alumno vea la ficha de otro cambiando un identificador?
• ¿Cómo se protege la recuperación de contraseña frente a abuso?
• ¿Qué datos personales se muestran y cuáles no deberían exponerse?
• ¿Cómo se registran cambios relevantes para poder auditarlos?
• ¿Qué ocurre si alguien automatiza miles de intentos de login o de consultas?
• ¿Cómo se separan funciones de alumno, docente y administrador?

La seguridad empieza cuando el equipo formula estas preguntas antes de que aparezca el incidente.

1.20 Qué aprenderemos en los próximos temas

Este primer tema establece el marco general. A partir de aquí iremos recorriendo los mecanismos concretos con los que se protege una aplicación web real.

• Funcionamiento de HTTP, navegadores, servidores y modelo cliente-servidor.
• OWASP Top 10 y principales categorías de riesgo.
• Validación, sanitización y fallas de inyección.
• XSS, CSRF y controles del lado navegador y servidor.
• Autenticación, autorización, sesiones, cookies y tokens.
• Protección de datos, cabeceras HTTP, hardening y configuración segura.
• Seguridad en APIs, monitoreo, registro, pruebas y mantenimiento continuo.

1.21 Qué debes recordar de este tema

• La seguridad en aplicaciones web protege datos, identidades, procesos y lógica de negocio, no solo páginas o formularios.
• Una aplicación funcional no necesariamente es una aplicación segura.
• La superficie de ataque incluye entradas, endpoints, sesiones, archivos, integraciones y configuraciones.
• Los controles críticos deben tomarse en el servidor, no confiar solo en el cliente.
• OWASP ayuda a organizar riesgos frecuentes, pero cada sistema necesita su propio análisis.
• La seguridad debe acompañar todo el ciclo de vida del software.

1.22 Conclusión

La seguridad en aplicaciones web es una disciplina esencial porque las aplicaciones modernas concentran usuarios, datos, decisiones y operaciones críticas. Protegerlas requiere entender su superficie de ataque, reconocer qué activos están en juego y asumir que cualquier entrada, integración o funcionalidad expuesta puede convertirse en un punto de abuso si no existe control.

En el próximo tema estudiaremos cómo funciona la comunicación web entre navegador, servidor y aplicación, porque comprender HTTP y el modelo cliente-servidor es indispensable para interpretar correctamente muchas vulnerabilidades y defensas.