Esta página estática se sirve desde la propia API OwaspTop10Demo.
Arranca la API (F5 en Visual Studio) y abre /index.html.
Cada pestaña llama a endpoints inseguros vs seguros para un riesgo OWASP.
¿Qué es? Inyección ocurre cuando datos controlados por el usuario se mezclan dentro de una consulta o comando (SQL, NoSQL, LDAP, etc.) sin saneo ni parametrización, permitiendo al atacante alterar la consulta ejecutada por el servidor.
¿Cómo se explota? El atacante envía payloads como
' OR 1=1 -- en campos de login o filtros. Si se concatenan directamente en la cadena SQL,
puede saltarse autenticación, extraer todos los registros, modificar o borrar datos.
Más info oficial: OWASP Top 10 – A03:2021 Injection
Usuarios válidos: alice/Password123, bob/Secret456, admin/AdminPass!
Prueba un payload de inyección: ' OR 1=1 -- como usuario.
– Aquí verás la consulta SQL ejecutada…
¿Qué es? Son errores en el uso (o ausencia) de criptografía que provocan exposición de datos sensibles: contraseñas en texto plano, cifrados débiles, claves reutilizadas, uso de algoritmos obsoletos, etc.
¿Cómo se explota? Si un atacante roba la base de datos y las contraseñas están en claro o con hashes débiles, puede recuperar rápidamente credenciales y usarlas dentro y fuera de la aplicación.
Más info oficial: OWASP Top 10 – A02:2021 Cryptographic Failures
Mira cómo cambia el campo PasswordHash.
– Aquí verás el JSON devuelto…
¿Qué es? Fallos de control de acceso permiten a un usuario hacer más de lo que debería: ver datos de otros usuarios, modificar recursos que no son suyos, invocar acciones administrativas, etc.
¿Cómo se explota? Normalmente cambiando IDs en la URL, manipulando parámetros o forzando
rutas (por ejemplo, probar /api/.../2 cuando el usuario sólo debería ver su propio ID 1).
Más info oficial: OWASP Top 10 – A01:2021 Broken Access Control
Usuarios demo: ID 1 (alice), 2 (bob).
Prueba con currentUserId=1 y id=2.
– Aquí verás el resultado o error (403/404)…
¿Qué es? Problemas de diseño (no sólo de implementación) que dejan huecos estructurales: ausencia de límites de negocio, falta de bloqueo tras muchos intentos, flujos inseguros por defecto, etc.
¿Cómo se explota? Un atacante puede lanzar fuerza bruta ilimitada, abuse de flujos lógicos (por ejemplo, reset de contraseña sin verificar identidad) o saltarse pasos críticos por mal diseño.
Más info oficial: OWASP Top 10 – A04:2021 Insecure Design
Haz varios intentos fallidos con la versión segura; verás un 429 Too Many Requests.
– Aquí verás estado y cuerpo de la respuesta…
¿Qué es? Errores en cómo identificamos y autenticamos usuarios: políticas de password débiles, tokens predecibles, sesiones sin expiración, falta de 2FA, etc.
¿Cómo se explota? Fuerza bruta, relleno de credenciales filtradas, robo de sesiones, uso de tokens fáciles de adivinar o que nunca expiran.
Más info oficial: OWASP Top 10 – A07:2021 Identification and Authentication Failures
– Aquí verás token y datos de sesión…
¿Qué es? Situaciones donde asumimos que código, datos o actualizaciones son de confianza, sin verificar su integridad (firmas, checksums, validaciones), permitiendo que contenido malicioso se ejecute o se aplique.
¿Cómo se explota? Un atacante puede modificar payloads de configuración, actualizaciones o datos serializados, inyectando cambios peligrosos que la aplicación acepta sin validar.
Más info oficial: OWASP Top 10 – A08:2021 Software and Data Integrity Failures
– Pulsa el botón para ver la configuración actual…
Inseguro: deserializa directamente a AppSettings sin validar.
Seguro: usa DTO con validaciones.
– Aquí verás la respuesta del update…
¿Qué es? Falta de logs de seguridad, logs incompletos o ausencia de monitoreo y alertas. Esto hace que los incidentes pasen desapercibidos o se detecten demasiado tarde.
¿Cómo se explota? Cualquier otra vulnerabilidad se vuelve más grave si no hay trazas: el atacante puede moverse lateralmente y exfiltrar datos sin que nadie lo note.
Más info oficial: OWASP Top 10 – A09:2021 Security Logging and Monitoring Failures
Prueba con monto <= 0. La diferencia real está en los logs del servidor.
– Aquí verás la respuesta. Revisa también la consola/logs del backend…
¿Qué es? SSRF aparece cuando la app permite al usuario indicar una URL y el servidor hace peticiones a esa URL sin validarla, pudiendo acceder a recursos internos o servicios protegidos.
¿Cómo se explota? El atacante pone URLs apuntando a localhost,
redes internas o endpoints de metadatos en cloud, usando al servidor como “proxy” hacia recursos que
desde fuera no son accesibles.
Más info oficial: OWASP Top 10 – A10:2021 Server-Side Request Forgery (SSRF)
Inseguro: hace la petición a cualquier URL. Seguro: sólo HTTP/HTTPS y hosts en lista blanca.
– Aquí verás el cuerpo de la respuesta (truncado)…
A05 – Security Misconfiguration: configuraciones por defecto, servicios expuestos, CORS
demasiado permisivo, headers de seguridad ausentes, etc.
Más info:
OWASP Top 10 – A05:2021 Security Misconfiguration
A06 – Vulnerable and Outdated Components: uso de frameworks, librerías o runtimes con
vulnerabilidades conocidas o sin mantenimiento.
Más info:
OWASP Top 10 – A06:2021 Vulnerable and Outdated Components
En Program.cs tienes una política CORS insegura y otra más segura:
options.AddPolicy("InsecureCors", policy => {
policy.AllowAnyOrigin()
.AllowAnyHeader()
.AllowAnyMethod();
});
Cambiar UseCors("FrontendPolicy") por "InsecureCors"
demostraría un anti-patrón (permitir cualquier origen).
En el .csproj se usa una versión antigua de Newtonsoft.Json:
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
En un entorno real deberías revisar CVEs y actualizar.
Por ejemplo: dotnet list package --outdated.