Seguridad Ofensiva

Las aplicaciones web se han convertido en el núcleo de nuestra existencia digital y, por tanto, en el objetivo principal de los ataques informáticos. La seguridad web no es un estado estático, sino un proceso dinámico que requiere una comprensión profunda tanto de las tecnologías de desarrollo como de las tácticas de explotación. Un profesional del pentesting debe ir más allá de los escaneos automatizados, adentrándose en la lógica de las aplicaciones para descubrir vulnerabilidades que los algoritmos suelen pasar por alto.

El éxito de una intrusión ética o de una evaluación de seguridad reside en la capacidad del consultor para adaptarse a pilas tecnológicas modernas, desde arquitecturas serverless hasta aplicaciones de una sola página (SPAs). Comprender cómo viaja la información y cómo la interpretan los navegadores es el primer paso para dominar el arte del compromiso de sistemas.

El Cimiento del Reconocimiento: Mapeo de la Superficie de Ataque

Antes de lanzar cualquier ataque, es fundamental entender el terreno. El reconocimiento o “Intelligence Gathering” permite identificar puntos ciegos en la infraestructura. No se trata solo de encontrar subdominios, sino de entender la relación entre ellos y los servicios que exponen.

La enumeración de subdominios puede realizarse de forma pasiva, consultando registros históricos de DNS, o activa, mediante ataques de fuerza bruta. Herramientas como Amass permiten consolidar datos de múltiples fuentes para ofrecer una visión clara de la infraestructura. Sin embargo, el análisis no termina ahí; el “fingerprinting” de aplicaciones web permite identificar versiones específicas de servidores, frameworks y bibliotecas que podrían contener vulnerabilidades conocidas.

Ejemplo práctico de enumeración activa:

Si un auditor desea descubrir rutas ocultas o archivos de configuración expuestos, puede utilizar herramientas de fuzzing de directorios. Por ejemplo, al ejecutar un escaneo sobre un dominio objetivo, se podrían encontrar carpetas como /backup/ o archivos como config.php.bak que revelan credenciales de base de datos o secretos de la aplicación.

Inyecciones en el Lado del Servidor: El Control del Flujo de Datos

Las inyecciones siguen siendo una de las amenazas más críticas. El principio fundamental es el mismo: la falta de sanitización de los datos suministrados por el usuario que terminan formando parte de una consulta o comando.

La inyección SQL (SQLi) permite a un atacante interferir con las consultas que una aplicación realiza a su base de datos. Existen diversas variantes, desde las basadas en error, que devuelven información técnica directamente en la respuesta HTTP, hasta las basadas en tiempo, donde el atacante infiere datos observando cuánto tarda el servidor en responder.

Ejemplo práctico de extracción de datos con UNION:

Supongamos un parámetro vulnerable en una URL: search.php?id=1. Un atacante podría intentar inyectar una sentencia UNION para concatenar resultados de otras tablas: search.php?id=-1' UNION SELECT 1,username,password FROM users-- Si la aplicación es vulnerable, en lugar del producto solicitado, el navegador podría mostrar el primer nombre de usuario y su respectiva contraseña almacenados en la base de datos.

La Evolución de las Inyecciones: SSTI y NoSQL

Con el auge de frameworks modernos, han surgido nuevas variantes de inyección. La Inyección de Plantillas del Lado del Servidor (SSTI) ocurre cuando un motor de plantillas (como Jinja2 o Mako) procesa datos del usuario como código propio. Esto puede escalar rápidamente a una Ejecución Remota de Código (RCE).

Ejemplo práctico de SSTI en Jinja2:

Un atacante que detecta que una aplicación refleja su entrada dentro de una plantilla puede intentar ejecutar comandos del sistema. Usando un payload como {{ self.__init__.__globals__.__builtins__.__import__('os').popen('id').read() }}, el servidor podría ejecutar el comando id y devolver el resultado directamente en la página web, confirmando el compromiso total del sistema.

Por otro lado, las bases de datos NoSQL como MongoDB no están exentas. Aunque no utilizan SQL, son vulnerables a ataques que manipulan objetos JSON para evadir la lógica de autenticación. Un payload común para saltarse un login sería enviar un objeto como {"username": {"$ne": null}, "password": {"$ne": null}}, donde el operador $ne (no igual) hace que la consulta sea verdadera para cualquier usuario.

El Navegador como Campo de Batalla: Ataques de Lado del Cliente

Los ataques de lado del cliente, como el Cross-Site Scripting (XSS), se centran en ejecutar código malicioso en el navegador de la víctima. El impacto puede variar desde la redirección del tráfico hasta el robo de cookies de sesión para el secuestro de cuentas.

El XSS basado en el DOM es particularmente interesante, ya que la vulnerabilidad reside totalmente en el código JavaScript del cliente que maneja datos de una “fuente” (como la URL) y los pasa a un “sumidero” (como innerHTML) sin la debida precaución.

Ejemplo práctico de XSS vía SVG:

Muchos filtros bloquean etiquetas <script>, pero permiten la subida de imágenes. Un archivo SVG es, en esencia, un documento XML que puede contener scripts. Un atacante podría subir un archivo con el siguiente contenido: <svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.cookie)"></svg> Al ser renderizado por el navegador, el script se ejecuta en el contexto del dominio de la aplicación, permitiendo el acceso a información sensible.

Manipulación de la Lógica de Negocio y Race Conditions

A veces, la vulnerabilidad no reside en el código técnico, sino en el diseño del proceso. Las fallas de lógica de negocio permiten a los atacantes abusar de las funciones legítimas de una aplicación para obtener beneficios no deseados, como duplicar saldos o comprar productos a precios ínfimos.

Las condiciones de carrera (Race Conditions) ocurren cuando una aplicación realiza múltiples operaciones de forma concurrente sin la debida sincronización. Si un atacante envía cientos de peticiones simultáneas, puede lograr que el servidor procese todas antes de actualizar el estado de una variable.

Ejemplo práctico de Race Condition en cupones:

Imagina un sistema que permite usar un cupón de descuento una sola vez. Si el atacante envía 50 peticiones de “aplicar cupón” en el mismo milisegundo, es posible que el sistema verifique el estado del cupón (aún no usado) para todas las peticiones antes de marcarlo como “quemado”. El resultado sería la aplicación múltiple del mismo descuento sobre una sola compra.

Persistencia y Evasión: Superando las Barreras del WAF

Los Firewalls de Aplicaciones Web (WAF) son la primera línea de defensa, pero no son infalibles. La mayoría se basa en firmas y expresiones regulares para detectar patrones maliciosos. Un consultor de seguridad debe conocer técnicas de ofuscación y codificación para evadir estas protecciones.

El uso de diferentes codificaciones (URL, Hexadecimal, Base64 o incluso Unicode) puede confundir a un WAF que no decodifica recursivamente la entrada. Además, aprovechar discrepancias entre cómo el WAF y el servidor final interpretan una petición (como en el Request Smuggling) permite “esconder” una petición maliciosa dentro de una legítima.

Conclusión: El Enfoque Proactivo de la Seguridad

El pentesting moderno requiere una mentalidad creativa y un conocimiento técnico riguroso. Desde el reconocimiento inicial hasta la explotación de fallas complejas en la lógica de negocio, cada paso proporciona información valiosa para cerrar las brechas de seguridad. La clave no es solo identificar el fallo, sino entender su raíz técnica para implementar defensas robustas, como la política de seguridad de contenido (CSP) o el uso de tipos de datos seguros, que protejan la integridad de la aplicación y la privacidad de sus usuarios.