Seguridad en el desarrollo de aplicaciones
Objetivos: Al terminar este tema, podrás…
- Explicar qué es una vulnerabilidad en una aplicación y por qué ocurren
- Identificar las fallas de seguridad más comunes según OWASP
- Describir los principios básicos que guían el desarrollo seguro
- Experimentar ataques reales contra aplicaciones en un entorno controlado
¿Por qué las aplicaciones son vulnerables?
Una aplicación de software es un conjunto de instrucciones escritas por personas. Y las personas cometemos errores. Cuando esos errores tienen consecuencias de seguridad, los llamamos vulnerabilidades.
Imagina que diseñas una caja fuerte de cartón. Funcionará perfectamente mientras nadie intente abrirla a la fuerza. Pero en el momento en que alguien la ataque deliberadamente, los errores de diseño quedan expuestos. El software tiene el mismo problema: fue diseñado para funcionar correctamente con usuarios normales, no para resistir a alguien que intente romperlo.
Las vulnerabilidades ocurren por razones predecibles:
- Errores de confianza: El programador asume que el usuario solo enviará datos válidos
- Errores de diseño: La lógica del sistema no contempla que alguien pueda actuar de mala fe
- Errores de implementación: Lo que era correcto en teoría está mal ejecutado en la práctica
- Componentes desactualizados: Software con fallas conocidas que no se ha actualizado
Como ingeniero de seguridad, tu rol no es escribir todo el código del sistema, sino anticipar dónde pueden fallar los supuestos y diseñar controles para prevenirlo.
Vulnerabilidades más comunes: OWASP Top 10
OWASP (Open Web Application Security Project) es una organización internacional sin ánimo de lucro que publica las 10 categorías de vulnerabilidades más críticas en aplicaciones web. Esta lista es el punto de referencia de la industria para priorizar problemas de seguridad.
1. Inyección
¿Qué es? La aplicación mezcla instrucciones del sistema con datos enviados por el usuario, permitiendo que un atacante “inyecte” sus propias instrucciones disfrazadas de datos normales.
Analogía: Imagina que llamas a una biblioteca y pides “el libro de García Márquez”. La bibliotecaria busca exactamente eso. Pero si dices “García Márquez. Y de paso, dame también acceso a todos los archivos restringidos”, una biblioteca mal diseñada podría seguir esas instrucciones al pie de la letra porque no distingue entre una petición normal y una manipulada.
Ejemplo real: Las bases de datos usan un lenguaje llamado SQL para guardar y buscar información. Si una aplicación web construye su búsqueda mezclando texto del usuario directamente con sus instrucciones internas, un atacante puede escribir instrucciones SQL en lugar de un término de búsqueda normal y así acceder a datos de otros usuarios, borrar registros, o extraer toda la base de datos.
Prevención: Tratar siempre los datos del usuario como datos, nunca como instrucciones. Separar claramente qué es una orden del sistema y qué es un valor externo.
2. Autenticación rota
¿Qué es? Los mecanismos para verificar quién eres están mal implementados, lo que permite que un atacante se haga pasar por otro usuario.
Ejemplos comunes:
- Contraseñas guardadas exactamente como las escribe el usuario (si alguien roba la base de datos, obtiene todas las contraseñas inmediatamente)
- No bloquear la cuenta después de muchos intentos fallidos (un programa puede probar millones de contraseñas automáticamente)
- Sesiones que nunca expiran (si alguien roba tu sesión activa, puede usarla indefinidamente)
Prevención: Las contraseñas nunca se almacenan directamente: se transforman en un valor irreversible llamado hash. Se limita el número de intentos de inicio de sesión. Se implementa autenticación de múltiples factores (MFA).
3. Exposición de datos sensibles
¿Qué es? La aplicación no protege adecuadamente información confidencial, ya sea mientras viaja por internet o mientras está almacenada.
Analogía: Enviar datos personales por internet sin cifrado es como mandar una postal: cualquier persona que la manipule durante el trayecto puede leer el contenido. Con cifrado (lo que indica el candado HTTPS en el navegador), es como mandar una carta sellada en un sobre que nadie puede abrir excepto el destinatario.
Prevención: Usar cifrado para transmitir datos sensibles y para almacenarlos. No guardar datos que no sean estrictamente necesarios.
4. Control de acceso roto
¿Qué es? Los usuarios pueden acceder a recursos o realizar acciones para las que no tienen permiso.
Ejemplo: Imagina que el enlace de tu perfil en una red social es red.com/perfil/1234. ¿Qué pasa si simplemente cambias el número en la barra de direcciones a red.com/perfil/1235? En una aplicación mal diseñada, verías el perfil privado de otra persona. Esto se llama IDOR (Insecure Direct Object Reference).
Prevención: Verificar en el servidor que el usuario que hace la petición realmente tiene permiso para acceder a ese recurso específico. El número en la URL no es un control de seguridad.
5. Configuración insegura
¿Qué es? El sistema funciona correctamente pero está mal configurado: contraseñas por defecto sin cambiar, información técnica interna expuesta en mensajes de error, funciones innecesarias activadas.
Ejemplo: Un servidor que muestra el mensaje de error completo con detalles técnicos internos cuando algo falla le está dando al atacante un mapa de cómo está construida la aplicación por dentro.
Prevención: Configurar los sistemas con el mínimo de privilegios y funcionalidades necesarios. Mostrar mensajes de error genéricos hacia el exterior, guardando los detalles técnicos solo en registros internos.
Principios del desarrollo seguro
Independientemente de los detalles técnicos de cada aplicación, el desarrollo seguro se guía por principios fundamentales:
Nunca confiar en datos externos
Todo dato que llega desde fuera de la aplicación —formularios web, parámetros en URLs, archivos cargados, datos de otras aplicaciones— debe ser verificado antes de procesarse. Asumir que el usuario siempre enviará datos correctos es el origen de muchas vulnerabilidades.
Mínimo privilegio
Cada parte del sistema solo debe tener acceso a lo que necesita para funcionar. Una sección que solo necesita leer datos no debe tener permiso para borrarlos. Si esa parte es comprometida, el daño queda limitado.
Defensa en profundidad
No depender de una sola barrera de seguridad. Si un atacante supera una capa, las siguientes deben detenerlo. Un sistema bien diseñado tiene múltiples capas independientes:
[Usuario] → [Verificar formato] → [Verificar identidad] → [Verificar permiso] → [Datos cifrados]
↑ ↑ ↑ ↑
Primera barrera Segunda barrera Tercera barrera Última barrera
Fallar de forma segura
Cuando algo sale mal técnicamente, el sistema debe asumir la posición más restrictiva. Si una verificación de permisos falla por un error inesperado, la respuesta correcta es “denegar acceso”, no “asumir que está permitido”.
Seguridad desde el diseño
Es mucho más fácil y económico contemplar la seguridad desde el inicio que agregarla después de que el sistema ya está construido. Una vulnerabilidad descubierta en la fase de diseño puede corregirse en horas. La misma vulnerabilidad descubierta en producción puede costar semanas de trabajo y millones en daños.
La seguridad en el ciclo de desarrollo
Históricamente, la seguridad se revisaba solo al final del proceso de desarrollo, justo antes de lanzar el sistema. Esto generaba dos problemas: el costo de corregir era altísimo (ya estaba todo construido), y muchas veces no había tiempo para hacerlo bien.
El modelo moderno se llama DevSecOps e integra la seguridad en cada etapa del proceso:
Tradicional: [Diseño] → [Desarrollo] → [Pruebas] → [Lanzamiento] → [SEGURIDAD]
↑ Tardío, costoso
DevSecOps: [Diseño] → [Desarrollo] → [Pruebas] → [Lanzamiento]
↑ ↑ ↑ ↑
Seguridad Seguridad Seguridad Seguridad
Esto significa que desde el momento de diseñar el sistema ya se piensa en amenazas, durante el desarrollo se revisa el código buscando errores de seguridad, durante las pruebas se intenta atacar el sistema de forma controlada, y al lanzarlo se configuran alertas y monitoreo.
Caso de estudio: Uber (2016)
¿Qué pasó? Se expusieron datos de 57 millones de usuarios y conductores, incluyendo nombres, correos, teléfonos y números de licencia de conducir.
¿Cómo ocurrió?
- Desarrolladores de Uber guardaron las “llaves” de acceso a su almacenamiento en la nube dentro del código del programa
- Ese código fue publicado en GitHub, una plataforma donde los programadores comparten código
- Atacantes encontraron esas llaves y las usaron para ingresar al almacenamiento de Uber
- Descargaron toda la base de datos de usuarios
Fallas de ingeniería:
- Las credenciales de acceso nunca deben estar escritas dentro del código fuente
- No había alertas cuando alguien accedía a volúmenes inusuales de datos
- No había rotación periódica de las llaves de acceso
Consecuencias: 148 millones de dólares en multas regulatorias, pérdida masiva de confianza de usuarios y conductores, y el despido del directivo de seguridad.
Lección: Una falla en principios básicos —no guardar secretos en el código— puede tener consecuencias catastróficas incluso para compañías tecnológicas con miles de ingenieros.
Conceptos clave
| Término | Definición |
|---|---|
| Vulnerabilidad | Falla en un sistema que puede ser explotada para causar daño |
| Validación de entradas | Verificar que los datos recibidos cumplen el formato esperado antes de procesarlos |
| SQL Injection | Ataque que manipula consultas a bases de datos mediante entradas maliciosas |
| XSS | Ataque que inyecta scripts en páginas web vistas por otros usuarios |
| Autenticación | Proceso de verificar la identidad de un usuario |
| Autorización | Proceso de verificar qué acciones puede realizar un usuario autenticado |
| DevSecOps | Modelo de desarrollo que integra la seguridad en todas las etapas del ciclo |
| OWASP | Organización que documenta y publica las vulnerabilidades más críticas en aplicaciones web |
Ponte a prueba
-
Análisis de escenario: Una aplicación de salud guarda las contraseñas de sus usuarios exactamente como las escriben (sin ninguna transformación). ¿Qué principio viola esto? Si su base de datos fuera robada, ¿cuál sería el impacto inmediato para los usuarios?
-
Identificación de vulnerabilidad: Estás revisando una aplicación de mensajería. Notas que el enlace de cada conversación privada tiene la forma
mensajes.com/conversacion/5. ¿Qué vulnerabilidad del OWASP Top 10 debería preocuparte? ¿Por qué? -
Diseño de controles: Una universidad quiere lanzar un portal donde los estudiantes consultan sus notas en línea. Elige tres principios de desarrollo seguro y explica cómo aplicarías cada uno en este contexto específico.
-
Caso Uber: Si fueras el ingeniero de seguridad revisando el proceso antes de que el código fuera publicado en GitHub, ¿qué habrías buscado para detectar el problema? ¿Qué proceso propondrías para que esto no volviera a ocurrir?
Laboratorio práctico: Explorar vulnerabilidades web reales
Tiempo estimado: 90 minutos Requisitos: Navegador web, cuenta gratuita en PortSwigger Web Security Academy Ética: Practicar únicamente en los laboratorios diseñados para entrenamiento. Aplicar estas técnicas en sistemas reales sin autorización explícita es un delito.
Objetivo
Experimentar de primera mano cómo funcionan los ataques más comunes contra aplicaciones web. No necesitas saber programación para completar estos laboratorios: PortSwigger te guía paso a paso en una aplicación vulnerable diseñada para aprender.
Preparación
- Crea una cuenta gratuita en portswigger.net/users/register
- Accede a la Web Security Academy
- Cada laboratorio tiene un botón “Access the lab” que abre una aplicación vulnerable lista para practicar
Parte 1: Inyección SQL (30 min)
Laboratorio: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data (nivel Apprentice)
Este laboratorio simula una tienda en línea con una vulnerabilidad de inyección SQL. Siguiendo las instrucciones del laboratorio, lograrás que la tienda muestre productos que normalmente están ocultos manipulando la URL de una categoría de productos.
Preguntas de reflexión:
- ¿Qué escribiste en la URL para explotar la vulnerabilidad? En tus propias palabras, ¿qué le “dijiste” a la aplicación para que mostrara datos que no debía?
- La aplicación tomó tu texto como si fueran instrucciones internas. ¿Qué principio de desarrollo seguro habría prevenido esta vulnerabilidad?
- En una aplicación real de tienda (no un laboratorio), ¿qué otros datos podría obtener un atacante explotando esta vulnerabilidad?
Parte 2: Cross-Site Scripting — XSS (30 min)
Laboratorio: Reflected XSS into HTML context with nothing encoded (nivel Apprentice)
Este laboratorio tiene una barra de búsqueda que no valida lo que el usuario escribe. Podrás hacer que la página ejecute instrucciones que no debería ejecutar, simplemente escribiéndolas en el campo de búsqueda.
Preguntas de reflexión:
- ¿Qué escribiste en la barra de búsqueda? ¿Qué ocurrió en la página?
- Imagina que esta vulnerabilidad está en la caja de comentarios de un sitio con miles de usuarios. ¿Cómo podría un atacante usar esto para robar información de otros usuarios que visiten ese comentario?
- ¿Por qué esta vulnerabilidad se llama “reflejado” (reflected)? ¿Qué se está reflejando y hacia dónde?
Parte 3: Control de acceso roto — IDOR (30 min)
Laboratorio: Insecure direct object references (nivel Apprentice)
Este laboratorio tiene un chat donde se pueden descargar transcripciones de conversaciones. La aplicación no verifica a quién le pertenece cada transcripción antes de permitir la descarga.
Preguntas de reflexión:
- ¿Cómo lograste acceder a datos de otro usuario? ¿Qué modificaste y cómo lo descubriste?
- ¿Qué verificación debería haber hecho la aplicación antes de permitirte descargar ese archivo?
- Piensa en una aplicación bancaria, médica, o de recursos humanos. ¿Qué información podría quedar expuesta a este mismo tipo de ataque?
Entregable
Escribe un informe de experiencia que incluya:
-
Para cada laboratorio (una sección por cada uno):
- ¿Qué hiciste para lograr el ataque? (en tus propias palabras, sin copiar del laboratorio)
- ¿Qué impacto tendría en una aplicación real? ¿Qué datos o capacidades obtendría el atacante?
- ¿Qué principio de desarrollo seguro se violó?
-
Reflexión general:
- ¿Cuál de las tres vulnerabilidades te parece más peligrosa en el contexto de una aplicación bancaria? ¿Por qué?
- Después de experimentar estos ataques, ¿qué tan fácil te pareció explotar estas vulnerabilidades? ¿Qué implica eso para el diseño de aplicaciones?
Criterios de evaluación
| Criterio | Puntos |
|---|---|
| SQL Injection: laboratorio completado y preguntas respondidas | 25 |
| XSS: laboratorio completado y preguntas respondidas | 25 |
| Control de acceso: laboratorio completado y preguntas respondidas | 25 |
| Reflexión general con argumentos sólidos | 25 |
Navegación: ← Anterior | Inicio | Siguiente: Control de acceso →