Introducción
En este capítulo de la guía CompTIA CySA+ se aborda uno de los pilares de la ciberseguridad: entender los ataques más comunes y saber cómo reducir su impacto. En un mundo donde los atacantes solo necesitan acertar una vez y los defensores deben estar siempre alerta, conocer las vulnerabilidades habituales y sus mitigaciones es clave.
Ideas principales
- Existen ataques muy conocidos que siguen funcionando porque las vulnerabilidades no se corrigen.
- Muchas amenazas se originan por entradas no validadas, malas configuraciones o errores de diseño.
- Las vulnerabilidades más comunes afectan a aplicaciones web, memoria, autenticación y control de accesos.
- Aplicar defensa en profundidad reduce el impacto de un fallo.
- El principio de mínimo privilegio, el parcheo y los logs son fundamentales.
Ataques de inyección (Injection)
Ocurren cuando una aplicación confía demasiado en lo que escribe el usuario y lo ejecuta como si fuera una instrucción válida.
Analogía: Es como si en un restaurante el camarero aceptara cualquier nota escrita por un cliente y la llevara directamente a la cocina sin comprobarla. Podría terminar cocinándose algo que no debería existir.
Ejecución remota de código (RCE)
Permite al atacante ejecutar comandos en el sistema víctima desde fuera.
Analogía: Como si alguien pudiera cambiar los canales de la televisión desde la calle.
Es una de las vulnerabilidades más graves porque puede dar control total del sistema.
Ataques XML (XML Attacks)
Los ataques XML se aprovechan de aplicaciones que procesan datos en formato XML sin validarlos correctamente. El problema no es el XML en sí, sino cómo lo interpreta el parser.
Uno de los más comunes es el XML Bomb (Billion Laughs), donde el atacante envía un XML diseñado para consumir todos los recursos del sistema.
El parser expande entidades una y otra vez hasta quedarse sin memoria o CPU.
Resultado: caída del servicio (Denegación de Servicio).
Idea clave: generar mucho contenido a partir de muy poco texto.
SQL Injection (SQLi)
El atacante introduce comandos SQL maliciosos para leer, modificar o borrar bases de datos.
Analogía: Una petición normal con órdenes peligrosas escondidas, como colar instrucciones dentro de una receta médica.
Tipos explicados fácil
Union-based SQL injection: el atacante usa UNION para mezclar su propia consulta con la consulta normal y así ver datos extra en la respuesta.
Error-based SQL injection: provoca errores en la base de datos para que el mensaje de error revele información útil.
Blind SQL injection: no ve datos directamente; prueba cosas y observa si la web responde “sí” o “no” de forma diferente.
Time-based SQL injection: es una versión de la anterior, pero la pista es el tiempo; si la web tarda más, el atacante deduce que la condición era verdadera.
Out-of-band SQL injection: la base de datos hace una conexión externa hacia un sistema del atacante, y así se filtra información por otro canal distinto al normal.
Second-order SQL injection: el texto malicioso se guarda primero en la base de datos y se ejecuta más tarde, cuando otra parte del sistema lo reutiliza.
Inference-based SQL injection: el atacante no ve la respuesta exacta, pero deduce información mirando el comportamiento de la app, como cambios en contenido, errores o tiempos.
La mitigación clave es usar consultas parametrizadas.
Cross-Site Scripting (XSS)
Este ataque aprovecha la confianza entre el navegador del usuario y una web legítima. La página muestra contenido sin validarlo y el navegador lo ejecuta creyendo que es seguro.
Como resultado, se ejecuta código malicioso directamente en el navegador de la víctima.
El atacante usa la web como intermediaria para robar cookies de sesión, capturar contraseñas o redirigir a páginas falsas.
Analogía: Como pegar una nota falsa en un tablón oficial y que todos crean que es válida.
Cross-Site Request Forgery (CSRF)
Este ataque hace que un usuario autenticado realice acciones sin saberlo ni quererlo.
El navegador envía peticiones válidas usando la sesión abierta, aunque el usuario no haya dado la orden.
Ejemplo: el usuario deja abierta la sesión del banco, entra en otra web maliciosa y su navegador envía una orden automática al banco.
Se mitiga con tokens CSRF y una correcta configuración de cookies.
Xss persistente
Un XSS persistente, también llamado XSS almacenado, es un tipo de ataque hacker donde alguien mete un código malicioso en una página web, y ese código se queda guardado ahí para siempre, afectando a todos los que la visitan después. Imagina que es como dejar una nota falsa en un tablero público de un edificio: cualquiera que pase por ahí la lee y le hace caso sin saber que es peligrosa.
Cómo funciona
El atacante escribe el código malo en un lugar donde la web guarda información de los usuarios, como un comentario en un foro o un perfil en una red social. La página no lo detecta como peligroso, lo guarda en su base de datos (como un archivador gigante), y cuando otro usuario carga esa página, el código se activa en su navegador. Esto pasa sin que la víctima haga nada especial, solo por visitar el sitio.
Por qué es peligroso
Puede robar datos personales como contraseñas, cookies de sesión o información bancaria, porque el código actúa como si fuera parte normal de la página. Afecta a muchas personas a la vez, no solo a una, y dura hasta que los dueños de la web lo limpien. Es como un virus que se propaga solo al leer un mensaje infectado.
Ejemplo simple
En un blog con comentarios, un hacker escribe un comentario invisible para humanos pero con código que dice "envía mis datos privados a este sitio malo". Todos los lectores del blog ejecutan ese código sin saberlo, y el hacker recibe su info. Sucede en sitios sin buenas defensas, como no filtrar lo que la gente escribe.
XSS no persistente o reflejado
Un XSS no persistente, también llamado XSS reflejado, es un ataque donde el código malicioso se ejecuta solo en el momento y solo para quien hace clic en un enlace trucado, sin quedarse guardado en la web. Es como un anzuelo en un email falso: si muerdes, te afecta solo a ti en ese instante, pero no a los demás.
Cómo funciona
El hacker crea un enlace o formulario con código malo (como un script que roba tus datos) y te lo envía por email, chat o redes sociales. Cuando haces clic y la página lo "refleja" de vuelta en la respuesta (por ejemplo, mostrando tu búsqueda), el código se activa en tu navegador sin guardarse en el servidor. No pasa nada si otros visitan la página normal.
Por qué es peligroso
Roba cookies, contraseñas o sesiones solo de la víctima que cae en la trampa, y es común porque usa engaños simples como phishing. Aunque no afecta a todos, es fácil de propagar masivamente con enlaces virales. Dura poco, solo mientras la víctima interactúa.
Ejemplo simple
Recibes un email: "Mira tu pedido en www.tienda.com/search?q=robaMisDatos()". Al abrirlo, la web muestra "Tu búsqueda: robaMisDatos()" y ejecuta el código en tu navegador, enviando tus datos al hacker. Sucede en barras de búsqueda o formularios sin filtros.
DOM
Un XSS basado en DOM es un tipo de ataque donde el hacker manipula la estructura interna de la página web directamente en tu navegador, sin que el código malo pase por el servidor. Es como si alguien alterara las piezas de un rompecabezas ya armado en tu pantalla, haciendo que funcione de forma inesperada solo para ti.
Cómo funciona
Sucede todo en el lado del cliente: el JavaScript de la página toma datos de la URL (como lo que escribes después del # o en parámetros) y los usa para cambiar el contenido sin verificar si son seguros. El código malicioso se ejecuta al instante en tu navegador, sin guardarse ni reflejarse desde el servidor. No deja rastro en los logs del sitio, lo que lo hace más sigiloso.
Por qué es peligroso
Puede robar cookies, sesiones o datos personales al modificar la página en tiempo real, y es difícil de detectar porque el HTML fuente parece normal. Afecta solo a quien visita el enlace trucado, pero usa fallos en el JavaScript del sitio. Es común en apps modernas con mucho código dinámico.
Ejemplo simple
Un enlace como www.sitio.com/#robaDatos() carga la página normal, pero el JavaScript lee el # y lo mete en la página, activando el código. Ves la página igual, pero ya envió tus datos al hacker; pasa en funciones que usan location.hash o document.write sin filtros.
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) es un ataque donde un hacker engaña a un servidor web para que haga peticiones a sitios o servicios que no debería poder alcanzar, como redes internas o datos privados. Piensa en el servidor como un mensajero confiable: el atacante le dice "ve a buscar esto" con una dirección falsa, y el servidor obedece desde su posición privilegiada, pasando firewalls que bloquearían accesos directos.
Cómo funciona
Sucede cuando una web acepta URLs de usuarios (por ejemplo, para cargar una imagen o consultar una API) sin verificarlas bien. El hacker cambia la URL por una interna como localhost, 127.0.0.1 o metadatos de cloud (ej. http://169.254.169.254/latest/meta-data/), y el servidor la visita por él. Todo pasa en el servidor, sin que el hacker acceda directamente.
Por qué es peligroso
Permite leer archivos sensibles, escanear puertos internos, acceder a bases de datos o servicios cloud privados, e incluso ejecutar código remoto. Afecta infraestructuras seguras porque usa la confianza del servidor hacia sí mismo, y es común en apps que procesan URLs de usuarios.
Ejemplo simple
En un sitio que carga avatares desde una URL que tú das, pones "http://localhost/admin/secrets". El servidor va ahí, lee datos privados y te los muestra (o envía) sin saber que es interno. Pasa en funciones de importación de imágenes o webhooks sin filtros.
Directory Traversal
Permite acceder a archivos fuera de la carpeta permitida usando rutas como ../.
Analogía: Abrir puertas internas que deberían estar cerradas.
Buffer Overflow
Sucede cuando se intenta meter más datos de los que caben en la memoria asignada.
Dos tipos de memoria:
- Stack: estática y estructurada
- heap: dinámica y sin estructura
Analogía: Llenar un vaso más allá del borde y derramar el contenido.
Prevención:
- Validación de las entradas.
- Privilegios mínimos
- Securización del código
- Protección en la ejecución del código
- Canario de pila (stack canaries): es como un sensor que se ejecuta si se sobrepasa el punto donde se podruciría el desborgamiento y que genera una alert si se produce.
- Aleatorización de memoria (ASLR): la memoria es dinamica y el atacante tiene más dificultad en averiguar donde estan los datos
- Prevención de ejecución de datos (DEP)
- Firma del código
- Aleatorización de Heap
Puede provocar ejecución de código malicioso.
Stack-based attack:
Heap-based attacks:
Saturan el espacio de memoria reservado para un programaInteger attack:
Se realaza mediante el uso de de datos de tipo integro (numérico)
Broken Access Control
Ocurre cuando no se impide que un usuario acceda a recursos que no le corresponden.
Analogía: Un viajero que entra en la cabina del pilotos de un avión
Broken Object Level Authorization:
Cuando hay exposición de datos via API, sucede cuando cambias un número en la dirección (URL) para ver datos de otra persona:
Tu perfil:
api.tienda.com/v1/usuarios/500Ataque: Cambias el
500por501y, de repente, puedes ver el nombre y la tarjeta de crédito del usuario 501.
Broken user authentication:
Broken Level authorizatio:
Cryptographic Failure:
Data Poisoning
El data poisoning consiste en manipular los datos con los que se entrena un modelo de inteligencia artificial o machine learning.
El atacante introduce datos falsos o sesgados para que el modelo aprenda mal y tome decisiones incorrectas.
- No ataca al sistema directamente, sino a su aprendizaje
- Puede pasar desapercibido
- Afecta a todas las decisiones futuras del modelo
Idea clave: si los datos están corruptos, el modelo también lo estará.
Escala de privilegios:
Se produce cuando un suario consigue privilegios de un usuario con un perfil superiorIdentification and Authentication Attacks
Un gran desafio en la aseguridad es proceso de verificar que una pernona es quien realmente dice ser. En este ambito también son conocidos varios tipos de ataque que se detallan a continuación:- Password Spraying: El atacante prueba una sola contraseña común (ej. Password123) contra muchos usuarios diferentes.
- Objetivo: Evitar que la cuenta se bloquee por intentos fallidos en un solo perfil.
- Detección:
- Muchos intentos de login en poco tiempo hacia múltiples sistemas.
- Muchos nombres de usuario que no existen o no siguen el formato de la empresa.
- Muchos bloqueos de cuentas en un periodo corto.
- Múltiples inicios de sesión exitosos (o fallidos) desde una misma dirección IP.
- Credential Stuffing: Usar listas de usuarios y contraseñas filtradas de un sitio (ej. una brecha en LinkedIn) para intentar entrar en otros sitios.
- Lógica: La gente suele reutilizar sus contraseñas.
- Impersonation (Suplantación): El atacante se hace pasar por un servicio legítimo (el servidor) robando sus llaves secretas o engañando al sistema de certificados (CA).
- Man-in-the-Middle (MITM): El atacante se pone en medio del usuario y el servidor. Engaña a ambos: el usuario cree que habla con el servidor, y el servidor cree que habla con el usuario. Así captura todo lo que dicen.
- Session Hijacking (Secuestro de sesión): Robar el "token" o la "cookie" de una sesión activa. Es como robarle el pase VIP a alguien que ya entró al club; el atacante entra sin necesidad de saber la contraseña.
Técnicas de Prevención (Las Defensas)
MFA (Multifactor): La defensa más efectiva contra ataques automatizados.
Políticas de Contraseñas: Obligar a que sean complejas y únicas.
CAPTCHA: Frena a los bots que intentan ataques masivos.
Rate Limiting (Limitación de tasa): Bloquear o ralentizar tras varios intentos fallidos desde una misma IP o dispositivo.
Encryption (Cifrado): Protege los datos para que, si hay un ataque MITM, el atacante no pueda leer nada.
Educación al usuario: Enseñar a no ignorar las advertencias de seguridad del navegador (certificados inválidos).
Local File Inclusion/ Remote File Inclusion Attacks
- LFI: el atacante pueden manipular ficheros alojados en el sevidor que le permiten acceder a datos sensibles
- RFI: el atacante manipula las entradas de de los usuarios para que accenda a recurso malicionos fuera del servidor
Rootkit:
Insecure Design Vulnerabilities
Las Insecure Design Vulnerabilities son fallos que se originan en el diseño del sistema, no en errores puntuales de código.
Idea clave: si el diseño es inseguro, el código no puede arreglarlo por sí solo.
Improper Error Handling
La aplicación muestra errores demasiado detallados, revelando información interna.
Dereferencing
El software intenta acceder a referencias de memoria inexistentes, provocando fallos o caídas.
Insecure Object Reference (IDOR)
Se exponen identificadores internos sin validar el acceso a nivel de objeto.
Race Condition
La seguridad depende del orden o tiempo de ejecución de las acciones.
Sensitive Data Exposure
Datos sensibles no se protegen adecuadamente mediante cifrado o controles.
Insecure Components
Uso de dependencias externas sin evaluar su estado de seguridad.
Insufficient Logging and Monitoring
Falta de registros y visibilidad sobre eventos de seguridad.
Security Misconfiguration
Configuraciones inseguras, credenciales por defecto o parches inexistentes.
Use of Insecure Functions
Uso de funciones peligrosas que no controlan límites ni validaciones.
End-of-Life or Outdated Components
Uso de software sin soporte ni actualizaciones.
Mitigación:
Algunas técnicas comunes para prevenir y mitigar el diseño inseguro son:
- Ciclo de vida de desarrollo seguro (SDLC): incluir la seguridad desde el inicio del desarrollo, con modelado de amenazas, prácticas de programación segura y pruebas de seguridad.
- Análisis de componentes: realizar un análisis de composición de software (SCA) para detectar y gestionar vulnerabilidades en librerías o componentes de terceros.
- Pruebas estáticas (SAST): usar herramientas que analicen el código fuente para encontrar fallos como funciones inseguras o condiciones de carrera.
- Pruebas dinámicas (DAST): usar herramientas que examinen la app en ejecución para detectar referencias inseguras u exposición de datos sensibles.
- Protección en tiempo de ejecución (RASP): implementar una solución que detecte y bloquee ataques en tiempo real.
- Controles de acceso: configurar permisos adecuados para evitar accesos no autorizados a datos o funciones críticas.
- Gestión de errores: manejar los errores de forma segura para evitar la filtración de información útil para atacantes.
- Gestión de configuraciones: mantener configuraciones seguras para reducir riesgos por fallos o mala configuración.
- Actualizaciones periódicas: mantener el software actualizado para corregir vulnerabilidades conocidas.
- Registro y monitoreo: implementar registros y monitoreo continuo para detectar y responder a incidentes de seguridad.
Conclusión / recordatorio para el estudio
La mayoría de las vulnerabilidades tienen el mismo origen: decisiones de diseño inseguras.
- Pensar como atacante
- Diseñar con seguridad desde el inicio
- Monitorizar constantemente
No puedes defender lo que no ves.
