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

A01:2025 – Control de Acceso Roto

El control de acceso impone políticas para que los usuarios no realicen acciones fuera de sus permisos asignados. Las fallas en este área generalmente conducen a la divulgación, modificación o destrucción no autorizada de 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 de Seguridad

La configuración insegura 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 inseguras

• Pasos para prevenir configuraciones inseguras, incluyendo herramientas de gestión de configuración y automatización

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

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

A04:2025 – Fallas Criptográficas

En general, todos los datos en tránsito deben ser cifrados en la capa de transporte (capa 4 OSI). Obstáculos anteriores, como el rendimiento de la CPU y la gestión de claves privadas/certificados, ahora se manejan gracias a las CPU que tienen instrucciones diseñadas para acelerar el cifrado (p. ej., soporte para AES) y a la simplificación de la gestión de claves y certificados mediante servicios como LetsEncrypt.org, además de que los principales proveedores de nube 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 cifrado adicional en tránsito (en la capa de aplicación, capa 7 OSI).

Por ejemplo, las contraseñas, los números de tarjetas de crédito, los registros de salud, la información personal y los secretos empresariales requieren protección adicional, especialmente si esos datos están sujetos a leyes de privacidad, por ejemplo, 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 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 una falla 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 ese código o comandos como si fueran parte del sistema. Esto puede conducir a consecuencias verdaderamente graves.

Aspectos Prácticos

• Análisis detallado de la inyección SQL, NoSQL, de SO y LDAP

• Técnicas de mitigación usando sentencias preparadas, consultas parametrizadas y escapado 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 riesgos del Top Ten. Tenga en cuenta que existe una diferencia entre el diseño inseguro y la 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 remediaciones diferentes.

Un diseño seguro aún puede tener defectos de implementación que lleven a vulnerabilidades que puedan ser explotadas. 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 perfilado de riesgos empresariales inherente al software o sistema que se está desarrollando, y por lo tanto, el fallo para determinar qué nivel de diseño de seguridad es requerido.

Aspectos Prácticos

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

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

A07:2025 – Fallas de Autenticación

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

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 de Software o Datos

Las fallas 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 no válidos o no confiables como si fueran confiables y válidos.

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

Una tubería CI/CD insegura que no consuma ni proporcione verificaciones de integridad del software puede introducir el potencial para acceso no autorizado, código inseguro o malicioso, o compromiso del sistema.

Otro ejemplo para esto es una CI/CD que recupera código o artefactos de lugares no confiables y/o no los verifica antes de su uso (verificando la firma o mecanismo similar).

Aspectos Prácticos

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

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

A09:2025 – Fallas en Registro y Alertas de Seguridad

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

El registro insuficiente, el monitoreo continuo, la detección y la alerta para iniciar respuestas activas ocurren en cualquier 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 filtraciones temprano

A10:2025 – Manejo Inadecuado de Condiciones Excepcionales

El manejo inadecuado de condiciones excepcionales en el software ocurre cuando los programas no previenen, detectan y responden a situaciones inusuales e impredecibles, lo que conduce a bloqueos, comportamientos inesperados y, a veces, vulnerabilidades.

Esto puede implicar uno o más de los siguientes 3 fallos:

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

• No identifica la situación mientras ocurre

• Responde mal o 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 (desplazamiento a la izquierda o shift left)

2. Tipos de vulnerabilidades detectables a través de 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, priorizar 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 (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, Lista de Materiales de Software, qué es y por qué es importante

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)