OWASP: A02 2025 - Security Misconfiguration

¿Qué es Security Misconfiguration?

Security Misconfiguration agrupa errores de configuración que exponen información, funcionalidades o servicios que deberían permanecer restringidos. El problema no suele estar en una vulnerabilidad compleja del código, sino en una opción insegura, un servicio innecesario, un modo de depuración activo o una configuración por defecto que llegó a producción.

En este artículo analizamos las siguientes áreas:

Headers de seguridad HTTP
Archivos y rutas expuestos
Paneles y servicios administrativos expuestos
Credenciales por defecto
Mensajes de error verbosos y modo depuración
Almacenamiento cloud expuesto
XML External Entity (XXE)
Configuraciones por defecto en CMS y frameworks

Headers de seguridad HTTP

Revisa las cabeceras devueltas por la aplicación:

curl -sI https://target.com

Presta atención, entre otras, a:

Content-Security-Policy
Strict-Transport-Security
Referrer-Policy
X-Content-Type-Options
X-Frame-Options

La ausencia de una cabecera no implica por sí sola un impacto alto. Debes relacionarla con el comportamiento de la aplicación.

Por ejemplo, la falta de protección frente a framing cobra relevancia si una página sensible puede cargarse dentro de un iframe y contiene acciones que un usuario podría ejecutar mediante engaño.

Archivos y rutas expuestos

Busca recursos que suelen quedar publicados accidentalmente durante despliegues:

/.env
/web.config
/phpinfo.php
/server-status
/backup.zip
/.git/

Ejemplo de comprobación manual

ffuf -u https://target.com/FUZZ -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt -fc 404

• -w: Utiliza el archivo proporcionado.
• -fc 404: Filtra y descarta las respuestas que devuelvan un código 404.

Un código 200 OK solo te indica que el servidor respondió con éxito, confirma que realmente corresponde al recurso esperado y no a una página genérica o un soft 404.

Repositorios y copias de seguridad

Ante el hallazgo de un repositorio expuesto u oculto, como .git, una copia de seguridad (.bak, .zip, .tar, .tar.gz) o un archivo de configuración accesible públicamente, el análisis inicial debe centrarse en determinar con precisión qué información ha quedado expuesta y cuál es su impacto potencial.

Este tipo de exposición puede permitir recuperar código fuente, configuraciones, historial de cambios, rutas internas, endpoints no documentados, volcados de bases de datos, información sensible o secretos como credenciales, tokens y claves API.

El acceso al código fuente o al historial del repositorio también puede facilitar la identificación de vulnerabilidades que resultan difíciles de detectar mediante un análisis exclusivamente externo, como errores de lógica o controles de autorización incorrectos.

Red Team OPSEC

Evita descargar repositorios o copias de seguridad completas cuando una muestra mínima sea suficiente para demostrar y documentar la exposición.

Algunas herramientas automáticas utilizadas para reconstruir repositorios Git expuestos pueden generar una gran cantidad de peticiones HTTP al intentar recuperar individualmente referencias y objetos del repositorio. Esto incrementa considerablemente el ruido generado durante la evaluación.

Cuando exista una copia comprimida accesible que contenga la información necesaria para validar el hallazgo, puede resultar preferible obtener ese único recurso en lugar de realizar cientos o miles de solicitudes individuales.

Paneles y servicios administrativos expuestos

Identifica interfaces de administración, monitorización, gestión o soporte que puedan estar accesibles desde redes o ubicaciones desde las que no deberían ser alcanzables. Algunos ejemplos habituales incluyen:

/admin
/manager
/grafana
/kibana
/jenkins
/phpmyadmin

La existencia de una interfaz administrativa no constituye por sí sola una vulnerabilidad. El análisis debe determinar si su exposición es coherente con la arquitectura prevista y si dispone de controles de acceso adecuados.

Comprueba especialmente si:

• La interfaz debería ser accesible desde la red o contexto evaluado.
• Existe autenticación y esta resulta adecuada para la sensibilidad del servicio.
• La interfaz revela versiones de software, nombres de host, usuarios, rutas, configuraciones u otra información interna.
• Existen credenciales por defecto, débiles o compartidas.
• Usuarios sin los privilegios necesarios pueden acceder a funciones administrativas.
• Es posible ejecutar acciones administrativas desde redes o contextos que no estaban previstos para ello.
• La interfaz expone funcionalidades especialmente sensibles, como ejecución de tareas, gestión de usuarios, acceso a secretos, modificación de configuraciones o despliegue de código.

Red Team OPSEC

Evita realizar intentos masivos de autenticación o probar listas extensas de credenciales por defecto salvo que este comportamiento esté expresamente contemplado en el alcance.

En muchos casos, la exposición de la interfaz, la identificación del producto y una validación mínima de los controles de acceso son suficientes para caracterizar el riesgo sin realizar acciones administrativas innecesarias.

Credenciales por defecto

El objetivo no es realizar un ataque de fuerza bruta, sino determinar si el sistema continúa utilizando credenciales predeterminadas proporcionadas por el fabricante o instalador.

Antes de realizar la comprobación, considera si existen mecanismos de bloqueo de cuentas, limitación de intentos, alertas de seguridad o autenticación multifactor que puedan verse afectados por las pruebas.

Red Team OPSEC

No conviertas la comprobación de credenciales por defecto en una prueba de fuerza bruta. Un número reducido de intentos dirigidos y documentados suele ser suficiente para validar el hallazgo.

Valora detener las comprobaciones si observas bloqueos de cuenta, incremento de tiempos de respuesta u otros indicios de mecanismos defensivos que puedan afectar a usuarios legítimos o generar ruido innecesario.

Mensajes de error verbosos y modo depuración

Durante la evaluación, provoca errores controlados mediante entradas inesperadas, parámetros inválidos, solicitudes mal formadas o rutas inexistentes con el objetivo de identificar si la aplicación revela información interna innecesaria. Por ejemplo:

curl -s "https://target.com/api/user?id=abc"

curl -s -X POST "https://target.com/api/login" \ 
    -H 'Content-Type: application/json' \ 
    --data-binary '{'

El objetivo no es generar fallos indiscriminadamente, sino comprobar cómo responde la aplicación ante condiciones de error y si la información devuelta al cliente excede lo necesario.

Busca especialmente:

• Stack traces completos o parciales.
• Rutas absolutas del sistema de archivos.
• Nombres de clases, paquetes, módulos o namespaces internos.
• Versiones exactas de frameworks, runtimes o componentes.
• Consultas SQL, nombres de tablas o estructuras de base de datos.
• Variables de entorno o valores de configuración.
• Credenciales, tokens, claves API u otros secretos.
• Nombres de host, direcciones IP privadas o identificadores internos.
• Información sobre servicios dependientes, colas, bases de datos o sistemas externos.
• Fragmentos de código fuente o plantillas.
• Mensajes propios de frameworks que indiquen que el modo debug se encuentra habilitado.

La gravedad del hallazgo depende de qué información se expone y cómo puede utilizarse. Un mensaje de error detallado puede facilitar el reconocimiento de la arquitectura, la identificación de tecnologías vulnerables, la preparación de ataques posteriores o, en casos más graves, revelar directamente secretos o información sensible.

Modo depuración (debug)

Presta especial atención a aplicaciones desplegadas con mecanismos de depuración habilitados en entornos accesibles.

Dependiendo del framework o plataforma, el modo debug puede exponer:

• Stack traces interactivos.
• Código fuente.
• Variables locales y de entorno.
• Configuración de la aplicación.
• Información sobre sesiones o solicitudes.
• Consolas de depuración.
• Funcionalidades destinadas exclusivamente a desarrollo.

Una interfaz de depuración accesible desde un entorno no previsto puede representar un riesgo considerablemente mayor que un mensaje de error verboso convencional, especialmente cuando permite interactuar con el proceso de la aplicación o acceder a información sensible.

Red Team OPSEC

Prioriza entradas simples y reproducibles que provoquen errores de forma controlada.

Evita generar grandes volúmenes de excepciones o utilizar payloads destructivos cuando errores de validación, tipos incorrectos o solicitudes mal formadas sean suficientes para comprobar el comportamiento.

Si identificas una consola o funcionalidad de depuración con capacidades sensibles, limita la interacción a la mínima necesaria para demostrar su exposición.

Almacenamiento cloud expuesto

Si la aplicación utiliza almacenamiento de objetos o servicios equivalentes en la nube, comprueba si existen contenedores, buckets u objetos accesibles de forma anónima o con permisos más amplios de lo previsto.

Por ejemplo, para un bucket cuya URL ya hayas identificado:

curl -s https://target-bucket.s3.amazonaws.com/ | head

El análisis debe diferenciar entre distintos escenarios:

• Lectura pública intencionada, como imágenes, JavaScript, hojas de estilo u otros assets estáticos.
• Listado público, que permite enumerar objetos aunque estos no estén enlazados desde la aplicación.
• Lectura pública no intencionada de documentos, backups, logs, exportaciones u otro contenido sensible.
• Exposición de metadatos, nombres de objetos, rutas internas o información sobre la estructura del almacenamiento.
• Escritura anónima, que puede permitir crear o sobrescribir objetos y aumenta considerablemente el impacto.
• Eliminación o modificación de objetos, cuando los permisos concedidos exceden lo necesario.
• URLs firmadas o temporales excesivamente permisivas, con una vigencia o alcance superior al esperado.

No asumas que existe una vulnerabilidad únicamente porque un objeto sea accesible públicamente. Determina si esa exposición es coherente con el diseño esperado de la aplicación y con la sensibilidad del contenido.

También conviene comprobar si los permisos se aplican únicamente a objetos concretos o si afectan al contenedor completo, ya que una política demasiado amplia puede exponer recursos adicionales que inicialmente no resultan evidentes.

Red Team OPSEC

Prioriza comprobaciones de lectura y enumeración que no modifiquen el contenido.

No pruebes capacidades de escritura, sobrescritura o eliminación sobre objetos legítimos salvo que estén expresamente autorizadas. Si es necesario validar permisos de escritura, utiliza únicamente recursos de prueba controlados y evita cualquier impacto sobre datos existentes.

Cuando una muestra mínima sea suficiente para demostrar la exposición, evita descargar grandes cantidades de objetos o contenidos completos.

XML External Entity (XXE)

XXE aparece cuando un parser XML permite resolver entidades externas controladas por el usuario. OWASP incluye este tipo de debilidad dentro de Security Misconfiguration cuando el procesamiento XML conserva capacidades innecesarias o inseguras.

Busca endpoints que acepten XML directamente o formatos que puedan contenerlo, como determinados documentos, importaciones o integraciones.

Una comprobación inicial puede utilizar una entidad externa que apunte a infraestructura bajo tu control:

<?xml version="1.0"?>
<!DOCTYPE test [
  <!ENTITY xxe SYSTEM "https://recurso-controlado.example/xxe">
]>
<test>&xxe;</test>

Si el servidor realiza una petición hacia el recurso controlado, existe evidencia de que el parser está resolviendo entidades externas.

Dependiendo de la configuración, XXE puede permitir lectura de archivos, SSRF o acceso a recursos internos. No es necesario avanzar hacia esos impactos cuando la resolución de entidades externas ya pueda demostrarse de forma segura.

Red Team OPSEC

Utiliza infraestructura bajo tu control para validar resolución externa.

Evita leer archivos sensibles o utilizar XXE para explorar redes internas si una interacción fuera de banda es suficiente para demostrar el problema.

Configuraciones por defecto en CMS y frameworks

Durante la evaluación, comprueba si el entorno de producción conserva configuraciones, funcionalidades o recursos propios de una instalación por defecto, desarrollo, diagnóstico o puesta en marcha que no deberían permanecer accesibles.

Aplica sobre los CMS y frameworks las comprobaciones descritas anteriormente teniendo en cuenta sus características y recursos conocidos.

El objetivo no es considerar vulnerable una tecnología por utilizar su configuración predeterminada, sino identificar qué funcionalidades o recursos permanecen expuestos de forma innecesaria.