Tema 16

16. Pruebas de seguridad web, herramientas y metodología básica

Entender vulnerabilidades es importante, pero saber cómo buscarlas, validarlas y documentarlas con criterio es lo que convierte el conocimiento teórico en práctica real. Las pruebas de seguridad web requieren método, contexto y una combinación equilibrada de observación manual, herramientas y razonamiento técnico.

Objetivo Aprender a evaluar una aplicación web con criterio técnico
Enfoque Reconocimiento, validación, herramientas y reporte
Resultado Pasar de mirar una app a analizar su superficie de ataque

16.1 Introducción

Las pruebas de seguridad web no consisten simplemente en ejecutar una herramienta automática o en probar payloads al azar. Un análisis serio requiere comprender cómo funciona la aplicación, qué expone, qué datos procesa, qué roles existen y qué caminos podrían permitir abuso, exposición o control no autorizado.

En la práctica, una evaluación de seguridad web combina varias capacidades: observar tráfico, identificar superficies de ataque, manipular solicitudes, interpretar respuestas, formular hipótesis, validar hallazgos y documentar impacto de manera útil para remediación.

Este tema ofrece una metodología básica y realista para comenzar a evaluar aplicaciones web con orden, evitando tanto la improvisación como la dependencia ciega de herramientas.

16.2 Qué significa probar seguridad web

Probar seguridad web significa analizar si una aplicación puede ser abusada, manipulada o comprometida más allá de lo que el negocio y el diseño pretendían permitir. No se trata solo de encontrar "bugs", sino de evaluar controles, supuestos y exposición real.

Una prueba puede perseguir distintos objetivos:

  • Descubrir vulnerabilidades técnicas.
  • Validar hipótesis de riesgo.
  • Medir madurez de desarrollo seguro.
  • Verificar si ciertos controles realmente funcionan.
  • Priorizar remediaciones según impacto.

16.3 Pensar como analista, no como scanner

Un error común en principiantes es depender demasiado de herramientas automáticas. Los escáneres son útiles, pero no entienden completamente el negocio, las relaciones entre objetos, la lógica de permisos ni el contexto operativo. Pueden encontrar cosas, pero también omitir fallas graves o generar falsos positivos.

Las herramientas aceleran la observación. El criterio técnico sigue siendo humano: entender qué hace la aplicación, por qué un comportamiento es riesgoso y cómo demostrarlo sin destruir contexto.

16.4 Fases básicas de una evaluación

Una metodología básica de pruebas web puede organizarse en varias fases encadenadas.

  1. Reconocimiento y mapeo de la aplicación.
  2. Identificación de superficies de ataque y flujos sensibles.
  3. Pruebas dirigidas sobre autenticación, autorización, entradas y salidas.
  4. Validación de hallazgos y análisis de impacto.
  5. Documentación clara para remediación.

No siempre estas fases son lineales; en muchos casos se retroalimentan a medida que se descubre nueva información.

16.5 Reconocimiento inicial

Antes de probar vulnerabilidades específicas, conviene entender la estructura general del sistema. El reconocimiento ayuda a responder preguntas básicas:

  • ¿Qué tipo de aplicación es?
  • ¿Hay frontend web, API, panel administrativo, subdominios o servicios auxiliares?
  • ¿Qué flujos son críticos para el negocio?
  • ¿Qué roles o perfiles parecen existir?
  • ¿Qué datos sensibles están involucrados?

Una evaluación sin buen reconocimiento suele degenerar en pruebas aisladas y poco útiles.

16.6 Mapeo de superficie de ataque

La superficie de ataque es el conjunto de puntos por los que el usuario o un sistema externo puede interactuar con la aplicación. Mapearla significa identificar rutas, formularios, endpoints, parámetros, cargas de archivos, mecanismos de sesión, integraciones y paneles de administración.

Cuanto mejor esté mapeada esa superficie, más focalizadas y eficientes serán las pruebas posteriores.

16.7 Qué observar durante la navegación

Mientras se usa la aplicación, conviene prestar atención a señales útiles:

  • Parámetros visibles en URL o cuerpos JSON.
  • Cookies y tokens manejados por el navegador.
  • Acciones que cambian estado.
  • Campos ocultos, filtros y formularios.
  • Roles aparentemente distintos entre usuarios.
  • Mensajes de error, redirecciones y respuestas inesperadas.
  • Recursos cargados desde terceros o desde APIs internas.

16.8 Herramientas habituales

Las herramientas no reemplazan el análisis, pero son fundamentales para observar y manipular la aplicación. Algunas categorías comunes son:

  • Proxy interceptador para ver y modificar solicitudes y respuestas.
  • Navegadores con herramientas de desarrollo.
  • Clientes HTTP y colecciones de requests.
  • Escáneres automáticos y utilidades de crawling.
  • Herramientas de análisis de contenido, headers y TLS.
  • Utilidades de fuzzing o repetición controlada de requests.

La clave no es usar muchas herramientas, sino usarlas con propósito claro.

16.9 El valor del proxy interceptador

Un proxy interceptador es una de las herramientas más valiosas para pruebas web porque permite observar el tráfico real entre cliente y servidor, modificar parámetros, repetir solicitudes, cambiar roles simulados y explorar cómo responde la aplicación ante variaciones controladas.

Desde seguridad, esto es importante porque muchas vulnerabilidades aparecen cuando dejamos de interactuar solo desde la interfaz visual y empezamos a hablar con la aplicación en sus propios términos.

16.10 Pruebas sobre autenticación y sesión

Una evaluación básica debería revisar:

  • Flujos de login y recuperación de cuenta.
  • Políticas visibles de contraseña y MFA.
  • Persistencia de sesión.
  • Logout y eventos de invalidación.
  • Comportamiento ante múltiples intentos y automatización.

Estas pruebas ayudan a detectar fallas que muchas veces tienen impacto directo en apropiación de cuentas.

16.11 Pruebas sobre autorización y acceso a objetos

Una parte crítica del testing web consiste en cambiar identificadores, variar rutas, usar distintos perfiles y probar funciones administrativas o de otro usuario para ver si la autorización realmente se aplica del lado servidor.

Esto suele incluir:

  • Intercambiar IDs.
  • Acceder a recursos de otros usuarios.
  • Invocar endpoints que la interfaz no muestra.
  • Probar distintas cuentas con diferentes roles.
  • Variar métodos HTTP y estados del flujo.

16.12 Pruebas sobre entrada y salida

Otra línea central de trabajo es observar cómo la aplicación trata datos controlados por el usuario. Aquí entran validación, sanitización, encoding y uso posterior de esa entrada.

Las pruebas suelen enfocarse en:

  • Campos de búsqueda y filtros.
  • Formularios de alta o edición.
  • Cargas de archivos.
  • Headers y cookies manipulables.
  • Salidas reflejadas o almacenadas en la interfaz.
  • Parámetros que impactan consultas, renderizado o comandos.

16.13 Pruebas manuales versus automáticas

Ambas tienen valor, pero sirven para cosas distintas.

Enfoque Fortaleza principal Limitación frecuente
Manual Entiende lógica, contexto y abuso del negocio Más lento y dependiente del criterio del analista
Automático Escala, repetición y cobertura mecánica de patrones No comprende bien la intención de negocio ni todas las relaciones

La práctica madura combina ambos enfoques.

16.14 Qué es un hallazgo válido

No toda observación es automáticamente una vulnerabilidad. Un hallazgo útil debería responder al menos estas preguntas:

  • ¿Qué comportamiento inseguro se observó?
  • ¿Cómo puede reproducirse?
  • ¿Qué impacto real tiene?
  • ¿En qué condiciones ocurre?
  • ¿Qué control faltó o falló?

La validación es esencial para evitar falsos positivos y para que la remediación sea accionable.

16.15 Importancia del contexto y del alcance

Una misma observación puede tener severidad muy distinta según el contexto. No es igual una falla en una cuenta pública de prueba que en un flujo financiero crítico. Tampoco es igual una exposición de datos anodinos que una de secretos, identidad o información regulada.

Por eso el testing útil no solo encuentra cosas; también las contextualiza correctamente.

16.16 Documentación de hallazgos

Documentar bien es parte del trabajo técnico. Un hallazgo mal explicado puede ser imposible de reproducir o de priorizar. Un buen reporte suele incluir:

  • Título claro del problema.
  • Descripción breve y precisa.
  • Pasos de reproducción.
  • Impacto esperado y realista.
  • Evidencia suficiente.
  • Recomendación de remediación o dirección técnica razonable.

16.17 Ética y seguridad durante la prueba

Incluso en contextos autorizados, conviene trabajar con criterio para no dañar innecesariamente la operación ni los datos. Un tester responsable evita generar impacto evitable, cuida evidencia y procura validar hallazgos de forma proporcional.

Buenas prácticas:

  • No destruir datos si no es indispensable para demostrar el problema.
  • Evitar cargas o automatizaciones excesivas fuera del alcance acordado.
  • Usar cuentas de prueba cuando sea posible.
  • Registrar con claridad qué se hizo y qué efecto tuvo.

16.18 Metodología mínima para un principiante

Una forma simple y útil de empezar es seguir siempre este orden mental:

  1. Entender qué hace la funcionalidad.
  2. Identificar qué datos entran y salen.
  3. Preguntarse qué pasaría si un usuario modifica esos datos.
  4. Probar con distintos roles, estados y contextos.
  5. Observar si el servidor valida realmente lo esperado.
  6. Evaluar impacto y documentar.

Este enfoque es más valioso que memorizar payloads sin entender el sistema.

16.19 Errores frecuentes al empezar

  • Probar sin entender antes el flujo de negocio.
  • Confiar ciegamente en resultados automáticos.
  • Buscar solo vulnerabilidades famosas y omitir lógica de negocio.
  • No cambiar de rol o contexto durante la prueba.
  • No guardar evidencia suficiente para reproducir hallazgos.
  • Confundir un error técnico visible con una vulnerabilidad explotable real.

16.20 Buenas prácticas generales

  • Empezar por reconocimiento y mapeo antes de atacar casos puntuales.
  • Usar herramientas para observar, no para reemplazar criterio.
  • Combinar navegación funcional con manipulación directa de requests.
  • Probar distintos roles, IDs, estados y caminos alternativos.
  • Validar siempre impacto y reproducibilidad.
  • Documentar con claridad y sin ambigüedad técnica innecesaria.

16.21 Relación con el resto del curso

Este tema funciona como puente entre conocimiento conceptual y práctica. Todo lo visto antes puede convertirse en hipótesis de prueba:

  • Autenticación y sesiones se prueban observando flujos, cookies y tokens.
  • Broken Access Control se prueba cambiando IDs y roles.
  • XSS y CSRF se prueban observando entrada, salida y contexto del navegador.
  • APIs inseguras se prueban manipulando payloads, respuestas y volumen de uso.

En otras palabras, la metodología ordena el conocimiento y lo vuelve operativo.

16.22 Qué debes recordar de este tema

  • Una prueba de seguridad útil combina contexto, método y validación.
  • Las herramientas ayudan, pero no reemplazan comprensión del sistema.
  • El reconocimiento inicial es clave para orientar el resto del análisis.
  • Hay que probar autenticación, autorización, entradas, salidas y lógica de negocio.
  • Un hallazgo vale por su reproducibilidad, impacto y claridad técnica.
  • Documentar bien es parte esencial del trabajo de seguridad.
  • El testing maduro mezcla observación manual con automatización útil.

16.23 Conclusión

Las pruebas de seguridad web convierten el conocimiento teórico en criterio práctico. Más que una lista de trucos, requieren entender la aplicación, pensar cómo podría ser abusada y usar herramientas para validar hipótesis con evidencia y orden. Una buena metodología no solo ayuda a encontrar vulnerabilidades; también mejora la calidad de las remediaciones y la madurez general del sistema.

En el próximo tema estudiaremos desarrollo seguro, hardening, cabeceras HTTP y defensa en profundidad, para cerrar el curso conectando vulnerabilidades, pruebas y medidas concretas de prevención desde el diseño hasta la operación.