Pruebas de Seguridad de Aplicaciones: OWASP Top 10, SAST, DAST y SCA

A01:2025 – Control de Acceso Roto

El control de acceso aplica políticas que impiden a los usuarios actuar fuera de sus permisos previstos. Las fallas en este ámbito suelen conducir a la divulgación no autorizada de información, la modificación o destrucción de todos los datos, o el desempeño de funciones de negocio fuera de los límites del usuario.

Aspectos Prácticos

• Ejemplos prácticos de control de acceso roto

• Controles de acceso seguros y mejores prácticas

A02:2025 – Configuración de Seguridad Inadecuada

La configuración de seguridad inadecuada ocurre cuando un sistema, aplicación o servicio en la nube está configurado incorrectamente desde la perspectiva de la seguridad, creando vulnerabilidades.

Aspectos Prácticos

• Ejemplos del mundo real de configuraciones inadecuadas

• Pasos para prevenir la mala configuración, incluida la gestión de configuraciones y herramientas de automatización

A03:2025 – Fallos en la Cadena de Suministro de Software

Los fallos en la cadena de suministro de software son quiebres o compromisos en el proceso de construcción, distribución o actualización de software. A menudo son causados por vulnerabilidades o cambios maliciosos en código de terceros, herramientas u otras dependencias en las que el sistema confía.

A04:2025 – Fallos Criptográficos

En general, todos los datos en tránsito deben estar cifrados en la capa de transporte (capa 4 del modelo OSI). Obstáculos anteriores, como el rendimiento de la CPU y la gestión de claves privadas/certificados, ahora se manejan mediante CPUs con instrucciones diseñadas para acelerar el cifrado (por ejemplo, soporte para AES) y la simplificación de la gestión de claves privadas y certificados por parte de servicios como LetsEncrypt.org, junto con los principales proveedores de nube que ofrecen servicios de gestión de certificados aún más integrados para sus plataformas específicas.

Más allá de asegurar la capa de transporte, es importante determinar qué datos necesitan cifrado en reposo y qué datos necesitan un cifrado adicional en tránsito (en la capa de aplicación, capa 7 del modelo OSI).

Por ejemplo, contraseñas, números de tarjetas de crédito, registros de salud, información personal y secretos comerciales requieren una protección adicional, especialmente si esos datos están sujetos a leyes de privacidad, como el Reglamento General de Protección de Datos (RGPD/GDPR) de la UE, o regulaciones como el Estándar de Seguridad de Datos de PCI (PCI DSS).

Aspectos Prácticos

• Análisis detallado de fallos criptográficos, como algoritmos de cifrado débiles o una gestión de claves inapropiada

• Importancia de mecanismos criptográficos robustos, protocolos seguros (SSL/TLS) y ejemplos de criptografía moderna en la seguridad web

A05:2025 – Inyección

Una vulnerabilidad de inyección es un defecto del sistema que permite a un atacante insertar código o comandos maliciosos (como código SQL o de shell) en los campos de entrada de un programa, engañando al sistema para que ejecute dicho código o comandos como si fueran parte del propio sistema. Esto puede tener consecuencias muy graves.

Aspectos Prácticos

• Desglose detallado de inyección SQL, NoSQL, de SO y LDAP

• Técnicas de mitigación utilizando sentencias preparadas, consultas parametrizadas y el escape de entradas

A06:2025 – Diseño Inseguro

El diseño inseguro es una categoría amplia que representa diferentes debilidades, expresadas como "falta o ineficacia en el diseño de controles".

El diseño inseguro no es la causa de todas las demás categorías de riesgos del Top Ten. Note que existe una diferencia entre diseño inseguro e implementación insegura. Distinguimos entre defectos de diseño y defectos de implementación por una razón: tienen causas raíz diferentes, se producen en momentos distintos del proceso de desarrollo y tienen remedios diferentes.

Un diseño seguro aún puede tener defectos de implementación que lleven a vulnerabilidades explotables. Un diseño inseguro no puede ser corregido por una implementación perfecta, ya que los controles de seguridad necesarios nunca fueron creados para defenderse contra ataques específicos.

Uno de los factores que contribuye al diseño inseguro es la falta de perfiles de riesgo de negocio inherentes al software o sistema que se está desarrollando, y por lo tanto, la incapacidad de determinar qué nivel de diseño de seguridad se requiere.

Aspectos Prácticos

• Exploraremos defectos de diseño que pueden conducir a vulnerabilidades, como la validación de entradas inapropiada

• Estudiar estrategias para arquitecturas seguras y principios de diseño seguro

A07:2025 – Fallos de Autenticación

Cuando un atacante logra engañar a un sistema para que reconozca a un usuario inválido o incorrecto como legítimo, está presente esta vulnerabilidad.

Aspectos Prácticos

• Problemas comunes de autenticación

• Estrategias de autenticación segura, como la autenticación multifactor y el manejo adecuado de sesiones

A08:2025 – Fallos de Integridad de Software o Datos

Los fallos de integridad de software y datos se relacionan con el código y la infraestructura que no protegen contra el tratamiento de código o datos inválidos o no confiables como si fueran confiables y válidos.

Un ejemplo de esto es cuando una aplicación confía en plugins, bibliotecas o módulos de fuentes no confiables, repositorios y redes de distribución de contenido (CDNs).

Un pipeline de CI/CD inseguro que no consume ni proporciona comprobaciones de integridad del software puede introducir el potencial de acceso no autorizado, código inseguro o malicioso, o compromiso del sistema.

Otro ejemplo es un CI/CD que descarga código o artefactos de lugares no confiables y/o no los verifica antes de usarlos (mediante la verificación de la firma o un mecanismo similar).

Aspectos Prácticos

• Enfocado en problemas como actualizaciones de software no confiables y manipulación de datos

• Mecanismos seguros de actualización y comprobaciones de integridad de datos

A09:2025 – Fallos en el Registro de Eventos de Seguridad y Alertas

Sin registro de eventos y monitoreo, los ataques y vulneraciones no pueden detectarse, y sin alertas es muy difícil responder rápidamente y de manera efectiva durante un incidente de seguridad.

El registro insuficiente, la falta de monitoreo continuo, detección y alertas para iniciar respuestas activas ocurren todo el tiempo.

Aspectos Prácticos

• Importancia de registrar información relevante para la seguridad y monitorear actividades sospechosas

• Herramientas y prácticas para el registro adecuado y el monitoreo en tiempo real para detectar vulneraciones a tiempo

A10:2025 – Manejo Inadecuado de Condiciones Excepcionales

El manejo inadecuado de condiciones excepcionales en software ocurre cuando los programas no logran prevenir, detectar y responder a situaciones inusuales e impredecibles, lo que lleva a bloqueos, comportamiento inesperado y a veces vulnerabilidades.

Esto puede involucrar una o más de las siguientes 3 fallas:

• La aplicación no previene que ocurra una situación inusual

• No identifica la situación mientras está ocurriendo

• Responde mal o no responde en absoluto a la situación posteriormente

SAST – Pruebas Estáticas de Seguridad de Aplicaciones

1. Qué es el análisis estático y cuándo ejecutarlo en el SDLC (shift left)

2. Tipos de vulnerabilidades detectables mediante SAST, código vulnerable vs código seguro

3. Resumen de herramientas SAST (p. ej., Semgrep, SonarQube, Checkmarx, dependiendo del stack del cliente)

4. Ejercicio práctico: ejecutar un escaneo SAST en un repositorio con vulnerabilidades introducidas deliberadamente, interpretar resultados y clasificar falsos positivos vs vulnerabilidades reales

DAST – Pruebas Dinámicas de Seguridad de Aplicaciones

1. Diferencia entre SAST y DAST, pruebas de caja negra en la aplicación en ejecución

2. Flujo de escaneo DAST, crawling, fuzzing, análisis de respuestas

3. Resumen de herramientas DAST (p. ej., OWASP ZAP, Burp Suite)

4. Ejercicio práctico: ejecutar un escaneo DAST en una aplicación de prueba vulnerable (p. ej., OWASP Juice Shop), identificar y validar los hallazgos

SCA – Análisis de Composición de Software

1. Riesgo de dependencias y bibliotecas de terceros, vulnerabilidades heredadas

2. SBOM, Software Bill of Materials (Lista de Materiales de Software), qué es y por qué importa

3. Resumen de herramientas SCA (p. ej., Dependency Check, Snyk, GitHub Dependabot)

4. Ejercicio práctico: ejecutar un escaneo SCA en un proyecto real, identificar dependencias vulnerables y construir un plan de remediación (actualizar, parchear, mitigar)