Tema 14
Las aplicaciones web concentran autenticación, datos, lógica de negocio e integraciones. Probarlas bien exige una metodología que combine OWASP, análisis manual, uso controlado de herramientas y comprensión del flujo real de usuarios.
Las aplicaciones web son uno de los objetivos más frecuentes en pruebas de penetración. Manejan sesiones, credenciales, perfiles, pagos, archivos, datos personales, APIs, permisos y procesos de negocio. Una falla web puede ir desde una cabecera ausente hasta acceso no autorizado a información crítica.
OWASP aporta referencias muy útiles, especialmente OWASP Top 10, Web Security Testing Guide y ASVS. Sin embargo, una prueba web profesional no debe limitarse a marcar casillas. Debe entender cómo funciona la aplicación y qué impacto tendría abusar de sus flujos.
Este tema presenta una metodología de pruebas web y una vista práctica del OWASP Top 10, preparando el terreno para los temas posteriores sobre inyecciones, XSS, CSRF, SSRF, autenticación y control de acceso.
Una aplicación web combina muchas capas: navegador, frontend, backend, base de datos, sesiones, permisos, infraestructura, APIs y servicios externos. Una vulnerabilidad puede aparecer en cualquiera de esas capas o en la forma en que interactúan.
OWASP Top 10 resume categorías de riesgos frecuentes y relevantes en aplicaciones web. Es una referencia para comunicar problemas, orientar pruebas y priorizar controles, pero no cubre todo lo que puede fallar.
| Categoría | Idea central | Ejemplo de impacto |
|---|---|---|
| Broken Access Control | Usuarios acceden a funciones o datos indebidos | Ver o modificar recursos de otros usuarios |
| Cryptographic Failures | Protección insuficiente de datos sensibles | Exposición de datos en tránsito o reposo |
| Injection | Entradas no confiables alteran consultas o comandos | Lectura, modificación o ejecución no autorizada |
| Insecure Design | El diseño no contempla amenazas importantes | Abuso de flujo aunque el código no tenga bugs obvios |
| Security Misconfiguration | Configuración débil o exposición innecesaria | Paneles, errores o archivos sensibles accesibles |
El Top 10 no es una metodología completa. Es una lista de categorías de riesgo. Una aplicación puede cumplir controles relacionados con el Top 10 y aun así tener fallas importantes de negocio, integración, autorización o proceso.
Debe usarse como mapa inicial, no como único criterio de cobertura.
Una prueba web ordenada evita saltar directamente a payloads sin comprender la aplicación. El flujo recomendado parte del contexto y avanza hacia validaciones específicas.
Antes de probar una aplicación web, hay que preparar navegador, proxy, usuarios, datos de prueba y reglas de alcance.
Mapear la aplicación significa entender sus rutas, flujos, funciones y datos. Este mapa permite saber qué probar y qué impacto tendría cada acción.
| Elemento | Qué observar | Riesgo posible |
|---|---|---|
| Rutas públicas | Login, registro, recuperación, documentación | Enumeración, abuso de flujos, exposición |
| Rutas autenticadas | Paneles, perfiles, operaciones, archivos | Control de acceso y datos sensibles |
| APIs | Endpoints, métodos, objetos, tokens | BOLA, autorización débil, abuso de endpoints |
| Archivos estáticos | JS, mapas, rutas internas, bundles | Fuga de endpoints o claves |
| Flujos de negocio | Compra, aprobación, cambio de datos | Abuso lógico o bypass de controles |
La autenticación verifica identidad. En pruebas web se revisa cómo se inicia sesión, cómo se recupera acceso, cómo se aplica MFA y cómo responde el sistema ante errores.
Las pruebas de credenciales deben respetar estrictamente el alcance y evitar fuerza bruta no autorizada.
Una sesión mantiene la identidad del usuario entre peticiones. Si la sesión se maneja mal, un atacante podría robar, reutilizar, fijar o prolongar acceso.
El control de acceso define qué puede hacer cada usuario. Es una de las áreas más críticas en pruebas web, porque muchas fallas no son visibles para escáneres automáticos.
| Tipo | Ejemplo | Prueba segura |
|---|---|---|
| Vertical | Usuario común accede a función admin | Comparar roles con cuentas de prueba |
| Horizontal | Usuario accede a recurso de otro usuario | Usar dos cuentas de laboratorio |
| Por objeto | ID manipulable en URL o JSON | Cambiar identificador entre recursos de prueba |
| Por función | Endpoint oculto pero accesible | Invocar función con rol no autorizado |
Las entradas no confiables pueden llegar desde formularios, URLs, cabeceras, cookies, JSON, XML, archivos, parámetros ocultos o APIs. Validarlas mal puede causar inyecciones, XSS, SSRF, traversal o errores de lógica.
La validación debe hacerse del lado servidor. El control en frontend mejora experiencia, pero no es una barrera de seguridad suficiente.
Las inyecciones ocurren cuando una entrada no confiable altera una consulta, comando, expresión o estructura interpretada por otro sistema. Incluyen SQL, NoSQL, comandos, LDAP, XPath, plantillas y otros contextos.
Señales comunes:
Cross-Site Scripting permite ejecutar JavaScript en el navegador de otros usuarios o en el propio contexto de la aplicación. Puede afectar sesiones, acciones de usuario, integridad de interfaz y exposición de datos.
Para validar, se deben usar payloads inocuos y cuentas de prueba. No debe capturarse cookies reales ni afectar usuarios productivos.
CSRF permite inducir a un usuario autenticado a ejecutar una acción sin intención. Aunque algunas arquitecturas modernas reducen el riesgo, sigue siendo relevante en aplicaciones con cookies y acciones sensibles.
Aspectos a revisar:
SSRF ocurre cuando la aplicación permite que el servidor realice solicitudes hacia destinos controlados por el usuario. Puede exponer servicios internos, metadatos cloud o endpoints no accesibles desde internet.
Validación segura:
La carga de archivos puede introducir riesgos de ejecución, almacenamiento de contenido malicioso, bypass de validaciones, sobreescritura, exposición pública o consumo de recursos.
| Control | Qué revisar | Riesgo |
|---|---|---|
| Tipo de archivo | Validación de extensión, MIME y contenido | Subida de archivos ejecutables o peligrosos |
| Nombre | Normalización y rutas | Path traversal o sobreescritura |
| Ubicación | Directorio público o privado | Acceso directo a archivos sensibles |
| Tamaño | Límites y manejo de errores | Consumo de almacenamiento o DoS |
| Procesamiento | Antivirus, conversión, metadatos | Vulnerabilidades en parsers o fuga de datos |
Muchos hallazgos web provienen de configuración débil: cabeceras ausentes, errores detallados, entornos de debug, directorios listables, archivos de respaldo o credenciales en configuración.
Las aplicaciones dependen de frameworks, librerías, paquetes y servicios de terceros. Un componente vulnerable puede afectar a toda la aplicación si está expuesto o si procesa datos no confiables.
La lógica de negocio define reglas propias de la aplicación: descuentos, límites, aprobaciones, cupos, roles, estados, orden de pasos y condiciones. Los escáneres rara vez entienden estas reglas.
Ejemplos de pruebas:
Muchas aplicaciones web modernas son interfaces sobre APIs. Probar solo la interfaz visual deja fuera endpoints, métodos, objetos y flujos que pueden ser abusados directamente.
La severidad depende de impacto real, exposición, datos afectados, privilegios requeridos y facilidad de explotación.
| Hallazgo | Impacto bajo | Impacto alto |
|---|---|---|
| Cabecera faltante | No habilita explotación directa | Agrava una vulnerabilidad explotable |
| XSS | Solo en perfil propio y con baja exposición | Almacenado en panel administrativo |
| IDOR | Accede a datos no sensibles de prueba | Expone documentos o datos personales |
| Inyección | Error controlado sin acceso a datos | Lectura o modificación de datos críticos |
| Debug expuesto | Solo información genérica | Secretos, variables o ejecución de código |
La evidencia web suele incluir peticiones, respuestas, capturas, roles y explicación del impacto. Debe cuidarse especialmente el manejo de tokens, cookies, datos personales y contenido sensible.
Un flujo útil para evaluar una aplicación web puede ser:
Las vulnerabilidades web requieren una combinación de método, herramientas y criterio. OWASP ayuda a ordenar la cobertura, pero el valor real aparece cuando se entiende cómo funciona la aplicación y qué impacto tendría abusar de sus controles.
En el próximo tema profundizaremos en inyección SQL, NoSQL, comandos y técnicas de validación segura, una de las familias de vulnerabilidades más relevantes en aplicaciones y servicios.