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 para que los usuarios no actúen fuera de sus permisos previstos. Las fallas suelen llevar a la divulgación no autorizada de información, modificación o destrucción de todos los datos, o al 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 Insegura

La configuración insegura ocurre cuando un sistema, aplicación o servicio en la nube se establece incorrectamente desde la perspectiva de la seguridad, creando vulnerabilidades.

Aspectos Prácticos

• Ejemplos reales de configuraciones erróneas

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

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

Las fallas en la cadena de suministro de software son interrupciones u otros compromisos en el proceso de construcción, distribución o actualización de software. A menudo son causadas por vulnerabilidades o cambios maliciosos en código de terceros, herramientas u otras dependencias en las que el sistema se basa.

A04:2025 – Fallas Criptográficas

En general, todos los datos en tránsito deben ser cifrados en la capa de transporte (capa 4 del modelo OSI). Las barreras 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 (p. ej., soporte AES) y la simplificación de la gestión de claves privadas y certificados mediante servicios como LetsEncrypt.org, con los principales proveedores de nube ofreciendo servicios de gestión de certificados aún más estrechamente 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 cifrado adicional en tránsito (en la capa de aplicación, capa 7 del modelo OSI).

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

Aspectos Prácticos

• Análisis detallado de fallas criptográficas, como algoritmos de cifrado débiles o gestión inadecuada de claves

• Importancia de mecanismos criptográficos robustos, protocolos seguros (SSL/TLS) y ejemplos de criptografía moderna en 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 shell) en los campos de entrada de un programa, engañando al sistema para que ejecute el código o los comandos como si fueran parte del sistema. Esto puede conducir a consecuencias verdaderamente graves.

Aspectos Prácticos

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

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

A06:2025 – Diseño Inseguro

El diseño inseguro es una categoría amplia que representa diferentes debilidades, expresadas como "diseño de controles ausentes o ineficaces".

El diseño inseguro no es la fuente de todas las demás categorías de riesgo del Top Ten. Nótese que hay una diferencia entre diseño inseguro e implementación insegura. Diferenciamos entre defectos de diseño y defectos de implementación por una razón: tienen causas raíz diferentes, ocurren en momentos diferentes 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 contribuyen al diseño inseguro es la falta de perfilado de riesgos de negocio inherente al software o sistema en desarrollo, y por lo tanto, el fallo para determinar qué nivel de diseño de seguridad se requiere.

Aspectos Prácticos

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

• Estudiaremos estrategias para la arquitectura segura y principios de diseño seguro

A07:2025 – Fallas 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, esta vulnerabilidad está presente.

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 – Fallas de Integridad del Software o Datos

Las fallas de integridad del software y datos se relacionan con código e infraestructura que no protege contra el tratamiento de código o datos inválidos o no confiables como confiables y válidos.

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

Un pipeline de CI/CD inseguro sin consumir y proporcionar verificaciones de integridad del software puede introducir el potencial de acceso no autorizado, código inseguro o malicioso, o compromiso del sistema.

Otro ejemplo de esto es un CI/CD que extrae 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

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

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

A09:2025 – Fallas en el Registro y Alertas de Seguridad

Sin registro y monitoreo, los ataques e intrusiones no pueden ser detectados, y sin alertas es muy difícil responder rápida y efectivamente durante un incidente de seguridad.

El registro insuficiente, el monitoreo continuo, la detección y las alertas para iniciar respuestas activas ocurren en todo momento.

Aspectos Prácticos

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

• Herramientas y prácticas para un registro adecuado y monitoreo en tiempo real para detectar intrusiones tempranamente

A10:2025 – Manejo Inadecuado de Condiciones Excepcionales

El manejo inadecuado de condiciones excepcionales en el software ocurre cuando los programas no logran prevenir, detectar y responder a situaciones inusuales e impredecibles, lo que lleva a fallas, 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 ocurre

• Responde mal o no responde en absoluto a la situación después

SAST – Pruebas Estáticas de Seguridad de Aplicaciones

1. Qué es el análisis estático y cuándo ejecutarlo en el SDLC (desplazamiento a la izquierda o 'shift left')

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

3. Visión general de herramientas de SAST (p. ej., Semgrep, SonarQube, Checkmarx, dependiendo del stack del cliente)

4. Ejercicio práctico: ejecutar un análisis SAST en un repositorio con vulnerabilidades introducidas deliberadamente, interpretar resultados, 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 del escaneo DAST, rastreo, fuzzing, análisis de respuestas

3. Visión general de herramientas de DAST (p. ej., OWASP ZAP, Burp Suite)

4. Ejercicio práctico: ejecutar un análisis 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), qué es y por qué importa

3. Visión general de herramientas de SCA (p. ej., Dependency Check, Snyk, GitHub Dependabot)

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