OWASP V1,3,4,10

OWASP ASVS 4.0.3

Capítulos V1 | V3 | V4 | V10

Alejandro, Enrique y Miguel CECETI

Índice

V1 - Arquitectura, Diseño y Modelado de Amenazas

V3 - Gestión de Sesiones

V4 - Control de Acceso

V10 - Código Malicioso

V1

Arquitectura, Diseño y Modelado de Amenazas

Objetivo de control

La arquitectura de seguridad casi se ha convertido en un arte perdido en muchas organizaciones.El campo de seguridad debe adoptar principios de seguridad ágiles , mientras que vuelve a aplicar los principios de seguridad punteros a los profesionales del software. Normalmente se ve a la seguridad como algo inflexible y exigente cuando es todo lo contrario, pues para un mismo problema un grupo de especialistas puede encontrar varias respuestas. No hay una solución única y sencilla para la arquitectura, y pretender lo contrario es un flaco favor al campo de la ingeniería de software. Si tomamos decisiones acertadas hoy en día, podemos ahorrar mucho esfuerzo, tiempo y dinero si seleccionamos y reutilizamos soluciones que cumplen con la arquitectura. Por ejemplo, hace una década, la autenticación multifactor rara vez se implementa.

Si los desarrolladores hubieran puesto su esfuerzo en desarrollar un único modelo estándar, como la identidad federada SAML. La mayoría de aplicaciones compartirían una misma arquitectura lo que beneficiaría a todas las partes. Este primer capítulo cubre los aspectos principales de cualquier arquitectura sólida; disponibilidad, confidencialidad, integridad del procesamiento, no repudio y privacidad. Los profesionales de la seguridad de las aplicaciones deben mantenerse al día con técnicas ágiles, lo que significa adoptar herramientas de desarrollo, aprender a codificar, y trabajar con desarrolladores en lugar de criticar el proyecto meses después de que todos los demás siguieron adelante.

V1.1 Ciclo de Vida de Desarrollo de Software Seguro

1.1.1: Verifique el uso de un ciclo de vida de desarrollo de software seguro que aborde la seguridad en todas las etapas del desarrollo

El ciclo de vida de desarrollo de software se aplica con el fin de desarrollar, implementar y mantener el software. Este está compuesto de entre 6 a 8 etapas:

• Planificación: determinar el alcance y la finalidad del software
• Análisis de los requisitos: definir las funciones que debe ejecutar el software
• Diseño: decidir los parámetros clave, como la arquitectura, las plataformas y las interfaces de usuario
• Desarrollo: crear e implementar el software
• Documentación: producir la información para que los usuarios y las partes interesadas puedan utilizar el sistema
• Pruebas: verificar que el software cumpla con los requisitos
• Implementación: poner el software a disposición de los usuarios
• Mantenimiento: solucionar los errores y los puntos vulnerables que se descubran en el sistema

1.1.2: Verifique el uso del modelado de amenazas para cada cambio de diseño o planificación de sprint para identificar amenazas, planificar contramedidas, facilitar respuestas de riesgo adecuadas y guiar las pruebas de seguridad.

1.1.4: Verifique la documentación y la justificación de todos los límites de confianza, componentes y flujos de datos significativos de la aplicación

El modelado de amenazas es una técnica que se aplica con el fin de encontrar vulnerabilidades de seguridad en una aplicación y su entorno. Consiste en crear una representación de una aplicación con todos sus componentes, para luego identificar los puntos débiles.Tanto los desarrolladores como ingenieros deben aplicar esta técnica desde los primeros momentos del desarrollo. Este punto nos comenta que la empresa debe contar con esta técnica para saber cómo gestionar una posible amenaza que aparezca con el fin de reducir lo máximo las pérdidas.

Es muy importante que desde la fase de desarrollo se lleve a cabo una buena documentación de los límites de confianza, así como componentes y flujos de datos. Pues si en etapas más avanzadas aparece una vulnerabilidad debido a la falta de documentación puede que se tarde más es busca una medida para solucionarla. La mejor solución es realizar desde un buen inicio una descripción detallada de lo que puede ser, por ejemplo, la separación básica de la Internet pública de la red corporativa interna en los niveles físico y lógico mediante un firewall y un enrutador

1.1.5: Verifique la definición y el análisis de seguridad de la arquitectura de alto nivel de la aplicación y todos los servicios remotos conectados

A día de hoy la mayoría de las empresas emplean escritorios remotos debido a la comodidad que supone no estar delante del equipo físicamente para solucionar un problema, haciendo así que aumente la productividad en la empresa. Sin embargo, es a su vez uno de los objetivos principales de los ciberataques debido al desconocimiento del empleado y a la potencial amenaza que supone obtener acceso no permitido al mismo. Es por esto que se debe tener un buen análisis de riesgos sobre el mismo, con el fin de protegerse sobre posibles amenazas y saber cómo reaccionar ante vulnerabilidades.

V1.2 Arquitectura de Autenticación

1.2.1: Verifique el uso de cuentas de sistema operativo únicas o especiales con privilegios bajos para todos los componentes, servicios y servidores de la aplicación.

Verificicación de autenticación

+ INFO

Es muy importante contar con un control de Autenticación que llegue a todas las capas del servicio, que además se adapte al nivel de credenciales de cada usuario. Siempre que sea posible, evite implementar rutinas de autenticación personalizadas y considere utilizar las capacidades de autenticación proporcionadas por el marco, el sistema operativo o el entorno circundante. Esto puede facilitar la provisión de una separación clara entre las tareas de autenticación y las tareas de autorización.

El producto realiza una operación con un nivel de privilegio superior al nivel mínimo requerido, lo que crea nuevas debilidades o amplifica las consecuencias de otras debilidades. La solución puede ser la creación de cuentas aisladas para el uso de esa aplicación.

V1.4 Arquitectura de CONTROL DE ACCESO

1.4.1: Verifique que los puntos de cumplimiento de confianza, tales como puertas de enlace de control de acceso, servidores y funciones serverless, exijan controles de acceso. Nunca aplique controles de acceso en el cliente.

1.4.4: Verifique que la aplicación utilice un mecanismo de control de acceso único y bien comprobado para acceder a datos y recursos protegidos. Todas las solicitudes deben pasar por este único mecanismo para evitar copiar y pegar o rutas alternativas inseguras.

Es muy importante que no se aplique el control de acceso desde el lado del cliente, debido a que un atacante puede modificar el comportamiento de este proceso para eludir los mecanismos de protección. Si se requiere cierto grado de confianza entre las dos entidades, utilice la verificación de integridad y una autenticación sólida para garantizar que las entradas provengan de una fuente confiable.

Cuando algún mecanismo no se aplica o falla, los atacantes pueden comprometer la seguridad del producto al obtener privilegios, leer información confidencial, ejecutar comandos, evadir la detección, etc. Es por ello que una técnica que se suele aplicar es la de crear áreas “seguras”, donde no permita que datos confidenciales salgan del límite de confianza y siempre tenga cuidado al interactuar con un compartimento fuera del área segura.

1.4.5 Verifique que se utiliza el control de acceso basado en atributos o entidades mediante el cual el código comprueba la autorización del usuario para un elemento de característica o datos en lugar de solo su rol. Los permisos deben asignarse mediante roles.

El 'Control de Acceso Basado en Atributos' (ABAC) proporciona acceso basado en características, comúnmente llamadas atributos. Hay tres tipos principales de atributos, los atributos del usuario como su id, rol u organización, los atributos ambientales como tiempo y ubicación del acceso y los atributos de los recursos como dueño del recurso, nombre del archivo y sensibilidad de los datos.

1.5 Arquitectura de Entradas y Salidas

1.5.1 Verifique que los requisitos de entrada y salida definan claramente cómo manejar y procesar datos en función del tipo, contenido y las leyes, regulaciones y otras leyes aplicables, reglamentos y otras normas de cumplimiento de políticas.

En ASVS el término “capa de servicio de confianza" se utiliza para referirse a cualquier punto de aplicación de confianza, independientemente de la ubicación, como un microservicio, serverless API, server-side, una API de confianza en un dispositivo cliente que tiene secure boot, partner o API externas, etc. El término "clientes que no son de confianza" aquí se refiere a las tecnologías del lado 'front-end'. El término "serialización" no sólo se refiere a enviar datos a través de las comunicaciones, como una matriz de valores o tomar y leer una estructura JSON, sino también pasar objetos complejos que pueden contener lógica.

1.5.2 Verifique que no se usa serialización al comunicarse con clientes que no son de confianza. Si esto no es posible, asegúrese de que se apliquen controles de integridad adecuados (y posiblemente cifrado si se envían datos confidenciales) para evitar ataques de deserialización, incluida la inyección de objetos.

1.5.3 Verifique que la validación de datos de entrada (input) se aplica en una capa de servicio de confianza

+ INFO

1.5.4 Verifique que la codificación de salida (output encode) se produce cerca o en el intérprete para el que está destinada.

+ INFO

1.6 Arquitectura Criptográfica

Es muy importante diseñar aplicaciones con una sólida arquitectura criptográfica para proteger los activos de datos según su clasificación. Cifrar todo es innecesario y no cifrar nada es una negligencia legal. Todos estos requisitos tienen asociado el CWE 320, que como tal es una categoría que engloba distintas vulnerabilidades asociadas al manejo erróneo de claves criptográficas.

1.6.2 Verifique que existe una política explícita para la administración de claves criptográficas y que un ciclo de vida de clave criptográfica sigue un estándar de administración de claves como NIST SP 800-57.

1.6.2 Verifique que los consumidores de servicios criptográficos protegen el material clave y otros secretos mediante el uso de almacenes de claves o alternativas basadas en API.

+ INFO

1.6.3 Verifique que todas las claves y contraseñas son reemplazables y forman parte de un proceso bien definido para volver a cifrar los datos confidenciales.

1.6.4 Verifique que la arquitectura trata los secretos del lado cliente (como claves simétricas, contraseñas o tokens de API) como inseguros y nunca los usa para proteger o acceder a datos confidenciales

+ INFO

1.7 Arquitectura de Errores, Logging y Auditoría

El logging es un concepto que la mayoría de los desarrolladores ya utilizan con fines de depuración y diagnóstico. El logging de seguridad es un concepto igualmente básico: registrar información de seguridad durante el funcionamiento en tiempo de ejecución de una aplicación.

1.7.2 Verifique que los registros de log se transmitan de forma segura a un sistema preferentemente remoto para análisis, detección, alertas y escalamiento.

1.7.1 Verifique que se utilice un formato común y un enfoque de logging en todo el sistema.

+ INFO

+ INFO

1.8 Arquitectura de Protección de Datos y Privacidad

1.8.2 Verifique que todos los niveles de protección tienen un conjunto asociado de requisitos de protección, como los requisitos de cifrado, los requisitos de integridad, la retención, la privacidad y otros requisitos de confidencialidad, y que estos se aplican en la arquitectura.

1.8.1 Verifique que todos los datos confidenciales se identifiquen y clasifiquen en niveles de protección.

• Cifrado: encriptar los datos para que solo los usuarios autorizados accedan a ellos.
• Integridad: Se contempla el uso de de algoritmos de ‘hashing’ y así asegurarse que la información no ha sido manipulada.
• Retención: Tiempos de expirado, copias de seguridad…
• Privacidad: Implementar controles de acceso (entre otras medidas).

Tener todo bien documentado y clasificado para datos confidenciales como información sensible, así como cumplir las leyes que así lo dictaminen como por ejemplo el Reglamento general de protección de datos (RGPD).

1.9 Arquitectura de Comunicaciones

¿En que se basa la arquitectura de comunicaciones?

Toda la información además de ser cifrada se encuentra en entornos seguros.

1.9.1 Cifrado de Comunicaciones

La arquitectura de comunicaciones en ciberseguridad se centra en garantizar la seguridad de la información que se transmite a través de redes y sistemas. -Cifrado de Datos. -Firewall para control de acceso. -VPN (Red Privada Virtual). -Actualización y parches. -Educación y concienciación .

Comunicación de forma segura, no existen problemas de por medio.

1.9.2 Autenticidad de cada lado

1.10 Arquitectura de Software Malicioso

Verificación continua del código

1.10.1 Sistema de control del código

Se debe tener un sistema de control del código fuente, así como el acceso y usuarios que han tenido acceso a los mismos.

1.11 Arquitectura de la lógica de negocio

Verificación de componentes

1.11.1

Conocer y documentar el alcance real de todos nuestros componentes así como su funcionamiento e implicaciones.

Flujos de alto valor

1.11.2

Verificación de las partes críticas de nuestra aplicación comprendiendo los objetivos clave y verificando la identidad de usuarios sin compartir estados.

Seguridad y robustez de flujos

1.11.3

Capacidad de los flujos para manejar operaciones multiples como llamada de subprocesos, destacanado el tiempo de ejecución real de los mismos verificando sus resultados en todo momento

V1.12 Arquitectura de carga segura de archivos

Esta instrucción se enfoca en la seguridad de los archivos subidos por los usuarios en una aplicación web. Los archivos que un usuario carga o envía a la aplicación deben estar validados ya sean en formato o incluso en contenido. En cuanto a la muestra o descarga de archivos desde la aplicación deberia hacerse utilizando secuencias de octetos, ya que esto garantiza que los archivos se manejen como datos binarios y no como código ejecutable. Recomenando que la muestra o descarga de archivos se haga desde un dominio no relacionado como podria ser almacenamiento en la nube

1.14 arquitectura de configuración

Configuración y actualización del entorno

1.14.1 Diferentes niveles de confianza

1.14.2 Verificación de firmas y conexiones

1.14.3 Advertencia de componentes obsoletos

Se ajustan diferentes niveles de confianza y seguridad, por medio de reglas corta fuegos, pasarelas de APi, grupos en la nube etc

Se verifican las firmas de componentes, así como las conexiones de confianza y puntos de conexión remoto.

Se realizan checkeos de nuestros componentes, así como se notifica si están desactualizados o no se utilizan.

1.14.5 Seguridad despliegue Aplicaciones

1.14.4 Automatización y Verificación

1.14.6 Uso de Tecnologia compatible

Se automatiza el flujo de tareas, se compila el código y verifica la seguridad del despliegue, así como ejecuta scripts de configuración en la nube

Verificación de despliegues en distintos contenedores y entornos, así como redes, para evitar ataques y errores.

Verificación de uso adecuado de software en lado cliente, que no estén en desuso, sean compatibles y no tengan brechas de seguridad.

V3

Gestión de sesiones

Objetivo de control

+ INFO

Uno de los componentes principales de cualquier aplicación basada en web o stateful API es el mecanismo por el cual controla y mantiene el estado de un usuario o dispositivo con el que interactúa. La gestión de sesiones cambia un protocolo ‘stateless’ a uno ‘stateful’. Las sesiones son únicas para cada individuo y no se pueden adivinar ni compartir. Las sesiones se invalidan cuando ya no son necesarias y se agota el tiempo de espera durante los períodos de inactividad. Los requisitos se han adaptado para ser un subconjunto compatible de los controles NIST (National Institute of Standards and Technology) 800-63b centrados en amenazas comunes y debilidades de autenticación comúnmente explotadas. Los requisitos de verificación anteriores han sido retirados, eliminado redundancias o adaptado para los requisitos obligatorios de NIST 800-63b.

Secciones

Listado de las secciones de este capítulo

3.2

3.3

3.4

3.1

Binding de Sesión

Terminación de Sesión

Gestión de Sesión Basada en Cookie

Seguridad Fundamental en la Gestión de Sesiones

Requisito/s

Requisito/s

Requisito/s

Requisito/s

3.5

3.6

3.7

Administración de Sesiones Basada en Tokens

Defensas Contra las Vulnerabilidades de Gestión de Sesiones

Re-autenticación Federada

Requisito/s

Requisito/s

Requisito/s

3.1.1 Verifique que la aplicación nunca revela tokens de sesión en parámetros de dirección URL.

Tiene asociado el CWE 598, que fue categorizado como Top Ten en la categoría de diseño inseguro de 2021: La aplicación web utiliza el método HTTP GET para procesar una solicitud e incluye información sensible en la cadena de consulta de dicha solicitud. Solución: Cuando se envíe información sensible, utilizar el método POST. En este caso para evitar que se revelen tokens de sesión. Por ejemplo: en la siguiente URL, incluso siendo información cifrada por HTTPS, sigue estando expuesta al ser enviada por HTTP GET. https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000 El método GET envía datos como parte de la URI1, mientras que el método POST envía datos como contenido HTTP. Por lo que las solicitudes GET se envían como una cadena en la URL, mientras que POST los manda en el cuerpo de la solicitud.

+ INFO

3.2 Binding de Sesión

3.2.2 Verifique que los tokens de sesión posean al menos 64 bits de entropía.

3.2.1 Verifique que la aplicación genera un nuevo token de sesión en la autenticación de usuario.

+ INFO

+ INFO

3.2.4 Verifique que los tokens de sesión se generan mediante algoritmos criptográficos aprobados.

3.2.3 Verifique que la aplicación solo almacena tokens de sesión en el navegador mediante métodos seguros, como proteger las cookies adecuadamente o el almacenamiento de sesión en HTML 5.

+ INFO

+ INFO

3.3 Terminación de Sesión

3.3.2 Si los autenticadores permiten a los usuarios permanecer conectados, compruebe que la re-autenticación se produce periódicamente tanto cuando se utiliza activamente o después de un período de inactividad.

3.3.1 Verifique que el cierre de sesión y la expiración invalidan el token de sesión, de modo que el botón "Atrás" o un usuario de confianza posterior no reanude una sesión autenticada, incluso entre los usuarios de confianza.

+ INFO

+ INFO

3.3.3 Verifique que la aplicación ofrece la opción de terminar todas las demás sesiones activas después de un cambio de contraseña correcto (incluido el cambio mediante el restablecimiento/recuperación de contraseña), y que esto es efectivo en toda la aplicación, el inicio de sesión federado (si está presente) y cualquier usuario de confianza.

3.3.4 Verifique que los usuarios pueden ver y (habiendo vuelto a introducir las credenciales de inicio de sesión) cerrar sesión en cualquiera o todas las sesiones y dispositivos activos actualmente.

+ INFO

+ INFO

3.4 Gestión de Sesión

3.4.1 Verifique que los tokens de sesión basados en cookies tengan el atributo 'Secure' establecido.

3.4.5 Verifique que si la aplicación se publica bajo un nombre de dominio con otras aplicaciones que establecen o usan cookies de sesión que podrían revelar las cookies de sesión, establezca el atributo de ruta en tokens de sesión basados en cookies utilizando la ruta más precisa posible.

+ INFO

+ INFO

3.4.2 Verifique que los tokens de sesión basados en cookies tienen el atributo 'HttpOnly' establecido.

+ INFO

3.4.3 Verifique que los tokens de sesión basados en cookies utilizan el atributo 'SameSite' para limitar la exposición a ataques de falsificación de solicitudes entre sitios.

SOLUCIONES

+ INFO

3.4.4 Verifique que los tokens de sesión basados en cookies utilizan el prefijo "__Host-" para que las cookies solo se envíen al host que configuró inicialmente la cookie.

+ INFO

3.5 Administración de Sesiones Basada en Tokens

3.5.2 Verifique que la aplicación utiliza tokens de sesión en lugar de claves y secretos de API estáticos, excepto con implementaciones heredadas.

3.5.1 Verifique que la aplicación permite a los usuarios revocar tokens de OAuth que forman relaciones de confianza con aplicaciones vinculadas.

+ INFO

+ INFO

3.5.3 Verifique que los tokens de sesión sin estado utilizan firmas digitales, cifrado y otras contramedidas para protegerse contra ataques de manipulación, envolvente, reproducción, cifrado nulo y sustitución de claves.

+ INFO

3.6 Re-autenticación Federada

3.6.2 Verifique que los proveedores de servicios de credenciales (CSP) informan a las partes de confianza (RP) del último evento de autenticación, para permitir que los RP determinen si necesitan volver a autenticar al usuario.

3.6.1 Verifique que las partes de confianza (RP) especifiquen el tiempo máximo de autenticación para los proveedores de servicios de credenciales (CSP) y que los CSP vuelvan a autenticar al usuario si no han utilizado una sesión dentro de ese período.

+ INFO

3.7.1 Verifique que la aplicación garantiza una sesión de inicio de sesión completa y válida o requiere una re-autenticación o verificación secundaria antes de permitir cualquier transacción confidencial o modificaciones de la cuenta.

Como ejemplo se propone CWE 306, la cual dice que el producto no realiza ninguna autenticación para las funciones que requieren una identidad de usuario demostrable o consumen una cantidad significativa de recursos. Es decir, no se ha verificado al usuario antes de realizar una acción. Otra opción podría ser, por ejemplo, implementar un método de re-autenticación así como 2FA (Google Authenticator, Authy…)

V4

Control de Acceso

Objetivo de control

La autorización es el concepto que se entiende como "el proceso de verificar que una acción o servicio solicitado esté aprobado para una entidad específica". En este punto hablaremos sobre los requisitos que las aplicación deben cumplir con requisitos de alta seguridad:

• Las personas que acceden a los recursos tienen credenciales válidas para hacerlo.
• Los usuarios están asociados a un conjunto bien definido de roles y privilegios.
• Los metadatos de roles y permisos están protegidos contra la reproducción o la manipulación.

SECCIONES

4.2

4.1

4.3

Control de acceso a nivel de operación

Otras concideraciones del control de acceso

Diseño y control de acceso general

4.1 Diseño de control de acceso general

4.1.1 Verifique que la aplicación aplica las reglas de control de acceso en una capa de servicio de confianza, especialmente si el control de acceso del lado cliente está presente y podría ser bypaseado

En la documentación se nos presenta el código CWE 602 donde podemos observar como la aplicación realiza la verificación correcta de la autenticación de usuario en el lado de este, enviando únicamente la confirmación al servidor. El servidor a su lado acepta dos comandos, AUTH que es la autenticación del usuario, y CHANGE-ADDRESS que modifica el campo de dirección de usuario. Por lo tanto, el cliente realiza la autenticación y envía un cambio de dirección para ese usuario si esta es tiene éxito.

Lado Cliente

POSIBLE SOLUCIÓN

Lado Servidor

4.1.2: Verifique que todos los atributos de usuario y datos y la información de directiva utilizada por los controles de acceso no pueden ser manipulados por los usuarios finales a menos que se autorice específicamente.

Viene relacionado al ejemplo CWE 639 donde se indica que la recuperación de un registro de usuario se produce en el sistema en función de algún valor clave que está bajo el control del usuario. La clave identificaría un registro relacionado con el usuario almacenado en el sistema y se usaría para buscar ese registro para presentarlo al usuario. Debemos asegurarnos que nuestra aplicación o página almacene de forma segura los identificadores con el fin de que alguien los obtenga mediante diferentes herramientas o técnicas.

Un ejemplo puede ser una web donde al crear un usuario se le enlace una uid que se genera de una lista continua de número por ejemplo 20, el atacante puede hacer mediante un ataque de fuerza bruta la comprobación de todas las uid desde el 1 hasta encontrar un usuario que le permite ascender autorización. Tras esto podría cambiar las cookies de la web y añadir la uid del usuario con permisos. Gracias a esto podrá cambiar la información del resto de usuarios. Posible solución: La solución se realiza en la Estructura y Diseños; para mitigar el peligro se debe cambiar el lado desde el cual se realiza la autenticación al lado del servidor, evitando así que el usuario tenga acceso a información como el Token que se genera.

4.1.3: Verifique que existe el principio de privilegios mínimos: los usuarios solo deben poder acceder a funciones, archivos de datos, direcciones URL, controladores, servicios y otros recursos, para los que poseen una autorización específica. Esto implica protección contra la suplantación y elevación de privilegios.

4.1.5: Verifique que los controles de acceso fallan de forma segura, incluso cuando se produce una excepción.

Suponiendo que un usuario tiene una identidad determinada, la autorización es el proceso de determinar si ese usuario puede acceder a un recurso determinado, en función de los privilegios del usuario y cualquier permiso u otras especificaciones de control de acceso que se apliquen al recurso. A día de hoy existe una técnica muy utilizada entre las empresas que tratan con datos muy sensibles, está es conocida como Zero Trust y se basa en el principio de privilegio mínimo, llevando además una seguimiento de los movimientos que hace el usuario dentro de la red de la empresa.

Cuando se crea un control de acceso se debe tener muy en cuenta que falle el control, pues con una mal diseño se puede generar una vulnerabilidad. Generalmente, se debe diseñar el código para que el fallo en el control de acceso tenga la misma ruta que una acceso erróneo.

4.2 Control de Acceso a Nivel de Operación

4.2.1: Verifique que los datos confidenciales y las API están protegidos contra ataques de referencia insegura directa de objetos (IDOR; por sus siglas en inglés) dirigidos a la creación, lectura, actualización y eliminación de registros, como la creación o actualización del registro de otra persona, la visualización de los registros de todos o la eliminación de todos los registros.

Las referencias directas a objetos son mapas de un identificador directamente a un recurso; son referencias directas a objetos inseguros cuando permiten que un usuario no autorizado acceda a los datos. Por ejemplo: un método que recupera un registro de una base de datos para luego mostrárselo a un usuario:

Este código de ejemplo es inseguro porque no verifica si el usuario autenticado está autorizado para ver ese registro. Un atacante puede simplemente cambiar el parámetro en la URL para ver cualquier registro que desee. Este tipo de ataque es fácil de automatizar, lo que puede provocar filtraciones masivas de datos.

POSIBLE SOLUCIÓN

4.2.2: Verifique que la aplicación o el framework aplica un mecanismo anti-CSRF seguro para proteger la funcionalidad autenticada, y eficaz anti automatización o anti-CSRF protege la funcionalidad no autenticada.

CSRF es una debilidad dentro de una aplicación web causada por una verificación insuficiente o ausente del origen de la solicitud HTTP. Los servidores web suelen estar diseñados para aceptar todas las solicitudes y responder a ellas. Un atacante podría obligar a un usuario a visitar una página web especialmente diseñada y realizar solicitudes de cambio de estado, como transferir fondos, cambiar su dirección de correo electrónico, etc.

Posible solución: Utilice el método de "cookie de doble envío" descrito por Felten y Zeller: Cuando un usuario visita un sitio, el sitio debe generar un valor pseudoaleatorio y configurarlo como una cookie en la máquina del usuario. El sitio debe exigir que cada envío de formulario incluya este valor como valor de formulario y también como valor de cookie. Cuando se envía una solicitud POST al sitio, la solicitud sólo debe considerarse válida si el valor del formulario y el valor de la cookie son los mismos.Debido a la política del mismo origen, un atacante no puede leer ni modificar el valor almacenado en la cookie. Para enviar con éxito un formulario en nombre del usuario, el atacante tendría que adivinar correctamente el valor pseudoaleatorio. Si el valor pseudoaleatorio es criptográficamente fuerte, esto será prohibitivamente difícil.

4.3 Otras Consideraciones del Control de Acceso

4.3.1: Verifique que las interfaces administrativas utilicen la autenticación multifactor adecuada para evitar el uso no autorizado.

Las interfaces administrativas cuentan con bastantes permisos dentro de la empresa, es por ello que deben utilizar herramientas de autenticación en multifactor con el fin de evitar posibles robos de credenciales o suplantaciones de identidad. A día de hoy existen diferentes maneras de combinar dos o más factores de autenticación. Los más comunes suelen ser la combinación de factores de herencias, como puede ser la huella dactilar o el reconocimiento facial, junto a un factor de conocimiento como puede ser una contraseña que el usuario sepa o más seguro aún un OTP. Para la generación de OTP existen muchos software tanto para equipos como para dispositivos móviles.

4.3.2: Verifique que la exploración de directorios está deshabilitada a menos que se desee deliberadamente. Además, las aplicaciones no deben permitir la detección o divulgación de metadatos de archivos o directorios, como Thumbs.db, .DS_Store, .git o .svn.

En cuanto a los metadatos de los archivos de nuestra empresa, debemos tener muy en cuenta que no estén ocultos en carpetas públicas, pues el atacante podría obtener la información mediante diferentes métodos:

Es importante que si no lo requieren los usuarios no tengan la posibilidad de explorar por los directorios.Para ello podemos restringir el acceso a directorios o archivos importantes mediante la adopción de un requisito de necesidad de conocer tanto para el documento como para la raíz del servidor, y desactivar funciones como los listados automáticos de directorios que podrían exponer archivos privados y proporcionar información que podría ser utilizada por un atacante al formular o realizar un ataque.

Observamos cómo el atacante mediante la herramienta dirb accede al sitio web y busca mediante un diccionario los directorios más comunes los cuales contienen información más importante.

4.3.3: Verifique que la aplicación tiene autorización adicional (como la autenticación paso a paso o adaptativa) para sistemas de menor valor y/ o segregación de tareas para aplicaciones de alto valor para aplicar controles antifraude según el riesgo de aplicación y fraudes previos.

Posible Solución: Una solución en la fase de arquitectura y diseño. Dividir el software en áreas anónima, normal, privilegiada y administrativa.Reduciendo el área de ataque definiendo con detenimiento cada grupo y asociandolos con los datos, la funcionalidad y los recursos relacionados. Luego configure los permisos en consecuencia. Esto le permitirá mantener un control más detallado sobre sus recursos.

Este punto viene relacionado con el CWE 732, en este nos dice que cuando a un recurso se le otorga una configuración de permiso que brinda acceso a una gama más amplia de actores de lo requerido, podría dar lugar a la exposición de información confidencial o a la modificación de ese recurso por parte de partes no deseadas. Esto es especialmente peligroso cuando el recurso está relacionado con la configuración, ejecución o datos confidenciales del usuario. Por ejemplo, considere una cuenta de almacenamiento mal configurada para la nube que un usuario público o anónimo puede leer o escribir.

V10

Código Malicioso

10.1 Integridad de Código

Nivel de riesgo elevado

Una aplicación para montar esto podria ser "SONARQUBE". SonarQube es una plataforma para evaluar código fuente. Es software libre y usa diversas herramientas de análisis estático de código fuente como Checkstyle, PMD o FindBugs para obtener métricas que pueden ayudar a mejorar la calidad del código de un programa.​

Este apartado sugiere que es importante asegurarse de que estás utilizando una herramienta de análisis de código que pueda identificar posibles amenazas de seguridad en tu código fuente. La detección de código malintencionado es crucial para prevenir vulnerabilidades y posibles ataques a tu sistema. Es habitual en grandes empresas que entre los trabajadores existan malas prácticas ya sean intencionadas, o simplemente errores humanos los cuales se deben revisar y corregir. Por esto, se necesita una revisión continua del código, validando en cada fase del desarrollo su funcionamiento e integridad.

+ INFO

10.2 Búsqueda de Código Malicioso

Nivel de riesgo elevado

10.2.2 Permisos

10.2.1 Recopilación de Datos

Verifique que la aplicación no solicite permisos innecesarios

Recopilación de datos o de "llamadas a casa".

10.2.4 Bombas de Tiempo

10.2.3 Puertas Traseras

Código fuente y bibliotecas de terceros no contienen bombas de tiempo.

Código fuente de la aplicación y las bibliotecas de terceros no contienen puertas traseras

10.2 Búsqueda de Código Malicioso

Nivel de riesgo elevado

10.2.6 Huevos de pascua

10.2.5 Código malintencionado

Código fuente de la aplicación y las bibliotecas de terceros no contienen huevos de pascua ni ninguna otra funcionalidad potencialmente no deseada.

Código fuente de la aplicación y las bibliotecas de terceros no contienen código malintencionado, como salami attacks, logic bypasses o bombas lógicas.

V10.3 Integridad de Aplicación

Regulación y gestión del riesgo

Cuando hablamos de la ejecución de código sin firmar, nos referimos a la posibilidad de que una aplicación permita la ejecución de instrucciones o scripts que no han sido debidamente verificados en términos de autenticidad y confiabilidad. Esto puede ocurrir, por ejemplo, cuando se permite a los usuarios cargar scripts personalizados o cuando la aplicación se integra con módulos o plugins externos.

ejemplos de Integridad

10.3.2 Fima de código e integridad

10.3.1.Actualizaciones Automáticas

La aplicación no debe cargar ni ejecutar código de fuentes que no sean de confianza

El código de actualización debe validar la firma digital de la actualización

10.3.3 Protección contra takeovers

vulnerabilidades relacionadas con entradas DNS y subdominios DNS. proyectos expirados en repositorios de código fuente público,

1.2.2: Verifique que las comunicaciones entre los componentes de la aplicación, incluidas las API, el middleware y las capas de datos, se autentican. Los componentes deben tener los mínimos privilegios necesarios. 1.2.3: Verifique que la aplicación utiliza un único mecanismo de autenticación comprobado que se sabe que es seguro, se puede ampliar para incluir una autenticación segura y tiene suficiente logging y supervisión para detectar abuso de cuenta o brechas. 1.2.4: Verifique que todas las vías de autenticación y las API de administración de identidades implementan una fortaleza coherente del control de seguridad de autenticación, de modo que no haya alternativas más débiles por el riesgo de la aplicación.

En lugar de depender de secretos del lado cliente para la seguridad de los datos confidenciales, se debería implementar una arquitectura que traslade la responsabilidad de manejar y proteger estos secretos al servidor. Por ejemplo, las contraseñas y claves simétricas deben ser manejadas y validadas en el servidor, y los tokens de API deben ser verificados y autorizados de manera segura.

• Un ejemplo sería el uso de un framework de logging como ‘Apache Logging Services’, que ayuda a proporcionar coherencia de logging entre aplicaciones Java, PHP, .NET y C++.
• No se debe registrar ni demasiado ni poco, pero se debe asegurar el registro de la marca de tiempo y la información de identificación, incluyendo la IP de origen y el ID de usuario, pero ten cuidado de no registrar datos privados o confidenciales.
• Se debe prestar mucha atención a la sincronización horaria entre nodos para garantizar la coherencia de las marcas de tiempo.

Los tokens de sesión son identificadores únicos que se generan después de que un usuario se autentica en una aplicación. Esto mejora la seguridad porque son temporales y suelen estar asociados a un conjunto limitado de permisos. Esto reduce el riesgo en comparación con el uso de claves y secretos estáticos que pueden ser comprometidos y utilizados de manera no autorizada ya que son identificadores que se utilizan para autenticar aplicaciones y servicios, siendo comparable a tener un usuario y contraseña, es decir, siempre es el mismo identificador mientras no se renueve. Solución: Utilizar herramientas de generación dinámica de tokens de sesión como JWT (JSON Web Tokens) o OAuth 2.0 entre otros.

'Stateful' y 'Stateless'

En pocas palabras, por ejemplo, una API ‘stateful’ mantiene información sobre las solicitudes anteriores, mientras que una API ‘stateless’ no. Lo mismo para la gestión de sesiones.

La selección de algoritmos criptográficos seguros es fundamental para garantizar la seguridad de sistemas y aplicaciones. Todos los tokens de sesión (independientes de los mecanismos de estado) deben ser únicos para el usuario, no predecibles y resistentes a la ingeniería inversa. Se debe utilizar una fuente de aleatoriedad de confianza para crear los tokens como un generador de números pseudoaleatorios (PRNG). Aún así, es más recomendable utilizar Cryptographically Secure Pseudo-Random Number Generators (CSPRNG), ya que están diseñados para producir una aleatoriedad de mucha mayor calidad lo que los hace seguros de usar para la seguridad de información sensible. Tokens de 32 bytes (256 bits) deberían ser suficientemente seguros. Solución: En Python por ejemplo, utilizar el módulo secrets() cuando se vayan a generar:

El atributo de cookie ‘HttpOnly’ indica a los navegadores web que no permitan a los scripts (por ejemplo, JavaScript o VBscript) acceder a las cookies a través del objeto DOM1 document.cookie. Esta protección de ID de sesión es obligatoria para evitar el robo de sesión mediante ataques XSS (Cross-site scripting). La cookie ‘HttpOnly’ sólo protege la confidencialidad de la cookie; el atacante no puede utilizarla offline, fuera del contexto de un ataque XSS. DOM1 (Document Object Model): define la manera en que objetos y elementos se relacionan entre sí en el navegador y en el documento.

POSIBLE SOLUCIÓN

En la fase de Arquitectura y Diseño; si se requiere cierto grado de confianza entre las dos entidades, utilice la verificación de integridad y una autenticación sólida para garantizar que las entradas provengan de una fuente confiable. Diseñe el producto para que esta confianza se administre de manera centralizada, especialmente si existen canales de comunicación complejos o numerosos, para reducir los riesgos de que el implementador omita por error una verificación en una única ruta de código.

Esto es una medida de seguridad importante para garantizar que solo el titular de la cuenta tenga acceso a la misma, ya que en caso de sospecha, a parte de haber cambiado la contraseña, tenga la opción de cerrar las sesiones activas.Ejemplo: Cambio de contraseña en Facebook (antiguo).

La re-autenticación periódica es una medida de seguridad importante para proteger las cuentas de usuario, especialmente cuando se utilizan autenticadores que permiten a los usuarios permanecer conectados. Solución: Para su máximo nivel (L3), es decir, para aplicaciones que requieren niveles significativos de verificación de la seguridad, como las que pueden encontrarse en ámbitos militares, de salud y seguridad, infraestructuras críticas, etc. Habría que implementar una manera de requerir re-autenticación cada 12 horas incluso usándose activamente, y cada 15 minutos de inactividad con 2FA.

Se trata de implementar en la aplicación una manera de que el usuario pueda gestionar sus sesiones de manera segura, fácil y clara. Ejemplo: Sesiones activas en Telegram. Tiene la opción de cerrar todas las sesiones directamente o alguna de ellas específicamente.

Herramienta de control de versionas diseñada para controlar grandes repositorios y flujos de trabajo complejo ofreciendo ramificación y fusión avanzada.

PLASTIC

Herramienta con interfaz por línea de comandos para interactuar con sistema de control de versiones git en Windows.

GIT BASH

Herramienta con interfaz gráfica y visual para el control de versiones Git, siendo esta multiplataforma.

GIT KRAKEN

Se puede relacionar con la CWE 331, la insuficiencia de entropía1, es decir, se utiliza un algoritmo o esquema que produce este problema, dejando patrones o grupos de valores que tienen más probabilidades de ocurrir que otros. Solución: Determinar la entropía necesaria para proporcionar adecuadamente aleatoriedad y previsibilidad. Esto puede lograrse aumentando el número de bits de objetos como claves y semillas, en este caso, a 64 bits. En PHP por ejemplo (versiones previas a 7.1.0), habría que cambiar en el archivo ‘php.ini’ el parámetro ‘session.entropy_length’ a 64 (es decir, serán 64 bits). Su valor por defecto es de 32. En versiones actuales esta opción no existe.

Entropía1: es la aleatoriedad recogida por un sistema operativo o una aplicación para su uso en criptografía u otros usos que requieran datos aleatorios.

Relying Party (RP)1: Entidad que confía en el autenticador o autenticadores y credenciales del suscriptor o en la afirmación de la identidad de un solicitante por parte de un verificador, normalmente para procesar una transacción o conceder acceso a información o a un sistema.

Credential Service Providers (CSP)2: Entidad de confianza que emite o registra autenticadores de suscriptores y expide credenciales electrónicas a ellos. Un proveedor de servicios de credenciales puede ser un tercero independiente o emitir credenciales para su propio uso.

La autenticación federada consiste en delegar a una entidad de confianza las tareas de obtener y guardar información de usuarios para su autenticación. La aplicación sigue manteniendo el control de autorizar qué recursos puede ver el usuario, pero se libera de la necesidad de autenticar cada usuario y asignarle los correspondientes roles o grupos convirtiéndose en un sistema de autenticación pasiva. Esto permite desacoplar la autenticación de la autorización y evitar que cada aplicación tenga que gestionar las credenciales de sus usuarios.

URI1

URI es la abreviatura de 'Uniform Resource Identifier'. Este término genérico se emplea para todos los tipos de nombres y direcciones que se refieren a objetos internet tales como páginas, imágenes, videos, etc.

'SameSite' es un atributo de cookie (similar a HTTPOnly, Secure, etc.) cuyo objetivo es mitigar los ataques CSRF1. Este atributo ayuda al navegador a decidir si envía cookies junto con las peticiones cross-site. Los valores posibles para este atributo son Lax, Strict o None. CSRF1 (Cross-site request forgery): es un tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía. Es decir, el atacante, mediante ingenieria social (por ejemplo eviando un link por email), ha conseguido engañar al usuario legítimo para que ejecute ciertas acciones maliciosas sin consentimiento.

Basados en la nube:

• Azure Monitor Logs.
• Google Cloud Logging.
• Amazon CloudWatch Logs.

Self-hosted:

• ELK Stack (Elasticsearch, Logstash, Kibana).
• Graylog.
• Splunk.

Las cookies son pequeños fragmentos de datos enviados por aplicaciones web y almacenados localmente en el navegador. Permiten a la aplicación transferir información entre páginas y guardar datos variables. La aplicación web controla qué información se guarda, como identificadores de sesión y personalización. Hay dos tipos de cookies: las de sesión, que solo existen en la memoria del navegador, y las persistentes, que se almacenan en el disco duro. Las cookies persistentes pueden plantear problemas de seguridad y privacidad dependiendo de la información almacenada y cómo se accede a ella. Solución: Tal y como dice el enunciado del requisito, utilizar métodos seguros de almacenamiento de cookies como:

• Utilizar la 'flag' HttpOnly en tus cookies para prevenir el acceso a los tokens desde scripts del lado del cliente, reduciendo el riesgo de ataques de Cross-Site-Scripting (XSS), es decir, de inyección de código malicioso en la web mediante lenguajes como javascript.
• Emplea la 'flag' Secure para garantizar que las cookies solo se transmitan sobre conexiones seguras, como HTTPS.

Open Authorization (OAuth) es un protocolo que permite a una aplicación autenticarse contra un servidor como usuario, sin requerir contraseñas ni ningún servidor de terceros que actúe como proveedor de identidad. Utiliza un token generado por el servidor y proporciona cómo se producen la mayoría de los flujos de autorización, de forma que un cliente, como una aplicación móvil, puede decirle al servidor qué usuario está utilizando el servicio. Solución: Para revocar un token OAuth de Google, habría que mandar una petición a la siguiente URL… https://accounts.google.com/o/oauth2/revoke?token={token} O revocar desde la API de Google Identity, por ejemplo.

La validación de las entradas debe aplicarse tanto a nivel sintáctico como semántico:

• La validación sintáctica debe garantizar la sintaxis correcta de los campos estructurados (por ejemplo, fecha, símbolo de moneda).
• La validación semántica debe garantizar la corrección de sus valores en el contexto empresarial específico (por ejemplo, la fecha de inicio es anterior a la fecha de finalización, el precio está dentro del intervalo previsto).

La validación de entrada puede implementarse utilizando cualquier técnica de programación que permita la aplicación efectiva de la corrección sintáctica y semántica, por ejemplo:

• Validadores de tipos de datos disponibles de forma nativa en frameworks de aplicaciones web (como Django Validators, Apache Commons Validators, etc).
• Conversores (por ejemplo, Integer.parseInt() en Java, int() en Python) con gestión estricta de excepciones.
• Comprobación del rango de valores mínimo y máximo para parámetros numéricos y fechas, comprobación de la longitud mínima y máxima para cadenas.

POSIBLE SOLUCIÓN

Agregar una verificación de autorización antes de mostrar cualquier información que pueda resultar útil para un atacante: Se suele usar este enfoque, ya que mientras su sistema de autorización sea efectivo, un usuario no autorizado no puede acceder a los datos a través de esta ruta, lo que dificulta mucho las cosas a los atacantes.

Con ello se podrá minimizar el periodo de tiempo durante el cual un atacante puede lanzar ataques sobre sesiones activas y secuestrarlas, por ejemplo. Se deben establecer tiempos de expiración para cada sesión, ya que una caducidad de sesión insuficiente por parte de la aplicación web aumenta la exposición a otros ataques basados en sesiones. Solución: Implementar una manera de invalidar los token de sesión para evitar reanudar sesiones anteriores con él. En PHP por ejemplo se podría hacer lo siguiente:

El atributo ‘Path’ indica a los navegadores web que sólo envíen la cookie al directorio o subdirectorios (o rutas o recursos) especificados dentro de la aplicación web. Si no se establece el atributo, por defecto la cookie sólo se enviará para el directorio (o ruta) del recurso solicitado y que establece la cookie. Solución: Asignar una ruta específica para que la cookie esté disponible solo en la ruta especificada.

Encoding (comúnmente denominado "output encoding") consiste en traducir caracteres especiales a alguna forma diferente pero equivalente que ya no sea peligrosa en el intérprete de destino, por ejemplo, traducir el carácter ‘<’ a la cadena ‘&lt;’ al escribir en una página HTML. Es decir, prevenir ataques de inyección de código malicioso. Por ejemplo, ataques de inyección de SQL o ataques de scripts entre sitios (XSS). Algunos frameworks como ‘Django’ para Python incluye protección para estos ambos ataques.

Por ejemplo, en el punto anterior se puede observar la implementación de uno de estos atributos, con ‘algorithm’, el cual hace referencia al tipo de algoritmo de firma utilizada en el token, en este caso ‘HS256 (HMAC SHA-256)’.

Solución: Comprobarlo como en el ejemplo anterior o también se puede utilizar la herramienta de OWASP Dependency Check1 para ver que las librerías estén actualizadas y se puedan implementar correctamente estas medidas.

Dependency-Check1 es una herramienta de análisis de composición de software (SCA) que intenta detectar vulnerabilidades de dominio público contenidas en las dependencias de un proyecto. Para ello, determina si existe un identificador de Enumeración de Plataforma Común (CPE) para una dependencia determinada. Si lo encuentra, generará un informe con un enlace a las entradas CVE asociadas.

El atributo de cookie ‘Secure’ indica a los navegadores web que sólo envíen la cookie a través de una conexión HTTPS (SSL/TLS) cifrada. Este mecanismo de protección de sesión es obligatorio para evitar la divulgación del ID de sesión a través de ataques MitM (Man-in-the-Middle). Garantiza que un atacante no pueda simplemente capturar el ID de sesión a partir del tráfico del navegador web.

Ejemplo de malas prácticas

Este código presenta prácticas inseguras, como ejecutar comandos ingresados por el usuario sin validación, escribir en archivos sin verificar permisos o existencia previa, y establecer una conexión de red sin cifrado. Estos errores son facilmente interpretables con erramientas de detección y pueden asumir un riesgo considerable en nuestras aplicaciones.

Como ejemplo tiene asociado el CWE 384. Este hace referencia a que a la hora de autenticar a un usuario, o establecer una nueva sesión de usuario, si no se invalida ningún identificador de sesión existente, dará a un atacante la oportunidad de robar sesiones autenticadas. Solución: Invalidar cualquier identificador de sesión existente antes de autorizar una nueva sesión de usuario. Por ejemplo, en PHP nunca aceptar identificadores de sesión como variables GET o POST. Sólo acepte identificadores de sesión de las cookies. Esto elimina la forma más fácil de establecer un identificador de sesión.

Si la cookie que se crea tiene en su nombre el prefijo ‘__Host-’:

• No puede ser escrita o sobreescrita desde otro subdominio.
• Debe tener el path: ‘/’.
• Debe estar marcada como ‘Secure’ (es decir, no puede enviarse a través de HTTP sin cifrar).

Cuando estén disponibles, deben utilizarse los mecanismos de almacenamiento seguro proporcionados por el sistema operativo, el framework o el proveedor de servicios en la nube. Entre ellos se incluyen:

• HSM (Hardware Security Module) físico o virtual.
• Almacenes de claves como Amazon KMS o Azure Key Vault.
• Un servicio externo de gestión de secretos como Conjur o HashiCorp Vault.
• API de almacenamiento seguro proporcionadas por la clase 'ProtectedData' del framework .NET.