Control de ASVS

Sergio Blanco
David Cubillos
Juliana Rodríguez

OBJETIVO

Los profesionales de seguridad

de aplicaciones deben
mantenerse al día con las
técnicas ágiles, lo que significa
adoptar herramientas de
desarrollo, aprender a codificar y
trabajar con los desarrolladores
en lugar de criticar el proyecto
meses después de que todos los
demás han seguido adelante.
 V1: Requisitos de
arquitectura,
diseño y modelado
de amenazas
En muchas organizaciones, la arquitectura de seguridad casi
se ha convertido en un arte perdido. En la era de DevSecOps, la
era de los arquitectos empresariales ha pasado. El campo de
la seguridad de las aplicaciones debe ponerse al día y adoptar
principios de seguridad ágiles al mismo tiempo que se
reintroducen los principios de arquitectura de seguridad líderes
para los profesionales del software. La arquitectura no es una
implementación, sino una forma de pensar sobre un problema
que puede tener muchas respuestas diferentes y no existe una
respuesta "correcta". Muchas veces, la seguridad se considera
inflexible y requiere que los desarrolladores corrijan el código
de una manera específica, y en este momento los
desarrolladores pueden conocer una mejor manera de resolver
el problema. No existe una solución única para la arquitectura,
que de otra manera pretende ser un daño para el campo de la
ingeniería de software.

V1.1 Requisitos de ciclo de vida de

desarrollo de software seguro
V1.2 Requisitos arquitectónicos de
autenticación
V1.3 Requisitos arquitectónicos de
gestión de sesiones
V1.4 Requisitos arquitectónicos de
control de acceso
V1.5 Requisitos arquitectónicos de
entrada y salida

V1.10 Requisitos
arquitectónicos de
software malicioso
V1.6 Requisitos V1.11 Requisitos
arquitectónicos arquitectónicos de
criptográficos lógica empresarial
V1.7 Errores, registro y V1.12 Requisitos
auditoría de requisitos arquitectónicos de
arquitectónicos carga segura de
V1.8 Requisitos archivos
arquitectónicos de V1.13Requisitos
protección de datos y arquitectónicos de la
privacidad API
V1.9 Requisitos V1.14 Requisitos
arquitectónicos de arquitectónicos de
comunicaciones configuración
V2: Requisitos de
verificación de
autenticación

La autenticación es el acto de
establecer, o confirmar, a alguien
(o algo así) como auténtico y que
las afirmaciones hechas por una
persona o sobre un dispositivo son
correctas, resistentes a la
suplantación y evitan la
recuperación o interceptación de
contraseñas.

Requisitos de seguridad de contraseña V2.1

V2.2 Requisitos generales del authenticator

Requisitos delciclo de vida del autenticador V2.3

Requisitos de almacenamiento de credenciales V2.4

Requisitos de recuperación de credenciales V2.5

Requisitos del verificador secreto de búsqueda V2.6

V2.7 Fuera de banda Requisitos del verificador

V2.8 Requisitos de verificador único o multifactor de

una sola vez

V2.9 Requisitos de verificador de software y

dispositivos criptográficos

Requisitos de autenticación de servicio V2.

Requisitos adicionales de la agencia estadounidense

V3: Requisitos de
verificación de
gestión de
sesiones

Uno de los componentes

principales de cualquier aplicación
basada en web o API con estado es
el mecanismo mediante el cual
controla y mantiene el estado de
un usuario o dispositivo que
interactúa con ella. La
administración de sesiones cambia
un protocolo sin estado a con
estado, que es fundamental para
diferenciar diferentes usuarios o
dispositivos.
Requisitos de verificación de
seguridad

V3.1Requisitos fundamentales
de gestión de sesiones

Requisitos de enlace de
sesión V3.2

Requisitos de cierre de sesión

y tiempo de espera de sesión
V3.3

V3.4 Gestión de sesiones

basada en cookies

Administración de sesiones
basada en tokens V3.5

V3.6 Re-autenticación de una

federación o aserción

V3.7 Defensas contra exploits

de gestión de sesiones

Descripción del ataque a

medias
Estándar de verificación de
seguridad de aplicaciones
4.0.2
V4: Requisitos de
verificación de control
de acceso
La autorización es el concepto de
permitir el acceso a los recursos
solo a aquellos a los que se les
permite utilizarlos. Asegúrese de
que una aplicación verificada
cumple los siguientes requisitos de
alto nivel:

•Las personas que acceden a los

recursos tienen credenciales
válidas para hacerlo.
•Los usuarios están asociados con
un conjunto bien definido de
roles y privilegios.
•Los metadatos de rol y permiso
están protegidos contra la
reproducción o la manipulación.
xto

Requisitos de verificación de seguridad

Diseño general de control de acceso V4.1

Control de acceso a nivel de operación V4.2

V4.3 Otras consideraciones de control de acceso

V5: Requisitos de
validación, desinfección
y verificación de
codificación

La debilidad de seguridad de la aplicación web

más común es el error de validar correctamente
la entrada procedente del cliente o del
entornoantes de usarla directamente sin ninguna
codificación de salida. Esta debilidad conduce a
casi todas las vulnerabilidades significativas en
aplicaciones web, como secuencias de
comandos entre sitios (XSS), inyección sql,
inyección de intérprete, ataques de configuración
regional / Unicode, ataques del sistema de
archivos y desbordamientos de búfer.

Requisitos de validación de entrada V5.1

Requisitos de desinfección y espacio

aislado V5.2

V5.3 Requisitos de codificación de salida y

prevención de inyección

Requisitos de memoria, cadena y código no

administrado V5.4

V5.5 Requisitos de prevención de

deserialización
V6: Requisitos de
verificación de
criptografía
almacenada

Asegúrese de que una aplicación

verificada cumple los siguientes
requisitos de alto nivel:

•Todos los módulos criptográficos

fallan de forma segura y que los
errores se controlan correctamente.

•Se utiliza un generador de números

aleatorios adecuado.

•El acceso a las claves se administra

de forma segura.

Clasificación de datos V6.1

Algoritmos V6.2

V6.3 Valores aleatorios

V6.4 Gestión secreta

V7: Requisitos de control
de errores y verificación
de registro

El objetivo principal del control y registro de

errores es proporcionar información útil
para el usuario, los administradores y los
equipos de respuesta a incidentes. El
objetivo no es crear cantidades masivas de
registros, sino registros de alta calidad, con
más señal que ruido descartado.Los
registros de alta calidad a menudo
contendrán datos confidenciales y deben
protegerse de acuerdo con las leyes o
directivas locales de privacidad de datos.
Esto debe incluir:

•No recopilar o registrar información

confidencial a menos que se requiera
específicamente.

•Garantizar que toda la información

registrada se maneje de forma segura y
protegida según su clasificación de datos.

•Asegurarse de que los registros no se

almacenan para siempre, pero tienen una
duración absoluta lo más corta posible.

Requisitos de contenido
de registro V7.1

Requisitos de
procesamiento de
registros V7.2

Requisitos de
protección de registros
V7.3

V7.4 Manejo de errores

8. Requisitos de
verificación de
protección de
datos

Confidencialidad: Los datos

deben estar protegidos contra la
observación o divulgación no
autorizadas.
Integridad: Los datos deben
protegerse atacantes no
autorizados.
Disponibilidad: los datos deben
estar disponibles

Datos privados
Datos confidenciales

Protección de datos
del lado del cliente
 9. Requisitos de
verificación de
comunicaciones

TLS o cifrado fuerte siempre se

utiliza
El consejo de configuración líder
más reciente se utiliza para
habilitar y ordenar algoritmos y
cifrados preferidos
Algoritmos y cifrados débiles como
último recurso
Los algoritmos y cifrados inseguros
obsoletos están deshabilitados.

Todas las comunicaciones

de cliente solo deben tener
lugar a través de rutas de
comunicación cifradas.

Las comunicaciones del

servidor son algo más que
HTTP. Deben establecerse
conexiones seguras desde y
hacia otros sistemas

TLS (Transport Layer Security,

seguridad de la capa de
transporte) es el protocolo
sucesor de SSL. TLS es una
versión mejorada de SSL.
10. Requisitos de
verificación de
código
malintencionado

Encontrar código malicioso es una prueba

de lo negativo, que es imposible de validar
por completo. Se deben realizar los mejores
esfuerzos para garantizar que el código no
tenga código malicioso inherente ni
funcionalidad no deseada.

Compruebe que se está

utilizando una herramienta de
análisis de código que puede
detectar código
potencialmente
malintencionado

Compruebe que el código

fuente de la aplicación y las
bibliotecas de terceros no
contienen capacidades no
autorizadas
Compruebe que la
aplicación no pide permisos
innecesarios o excesivos
Compruebe que el código
fuente de la aplicación y las
bibliotecas de terceros no
contienen puertas traseras

Las aplicaciones deben

protegerse contra ataques
comunes, como la ejecución
de código sin firmar de
fuentes no confiables
 11. Requisitos de
verificación de
lógica empresarial

El flujo de lógica empresarial es

secuencial
La lógica de negocios incluye límites
para detectar y prevenir ataques
automatizados
Protecciones contra la suplantación,
manipulación, repudio, divulgación
de información y elevación de
ataques de privilegios

La aplicación solo procesará

flujos de lógica empresarial
para el mismo usuario en orden
de paso secuencial y sin omitir
pasos.
Límites adecuados para
acciones empresariales
Controles anti-automatización

Validación para protegerse

contra riesgos o amenazas
empresariales probables
Alertas configurables
cuando se detectan
ataques automatizados o
actividad inusual.
12. Requisitos de
verificación de
archivos y recursos

Los datos de archivos que no son de

confianza obtenidos de orígenes que no
son de confianza se almacenan fuera de
la raíz web y con permisos limitados.
Los datos de archivo que no sean de
confianza deben tratarse en consecuencia
y de forma segura

Validar el tamaño de los

archivos.
Aplicar una cuota de tamaño
de archivo y un número
máximo de archivos
Validar el tipo de archivo

Comprobar los
metadatos del archivo
Protección contra
descargas de archivos

servir solo archivos con

extensiones de archivo
específicas para evitar la
información involuntaria y la
fuga de código fuente.
 13. Requisitos de
verificación de API
y servicios web

Autenticación adecuada y gestión

de sesiones
Seguridad para nuestras APIs
Validar los parámetros recibidos en
nuestra API

Las URLs no muestran

información confidencial
Retornar códigos de
respuesta adecuados
Limitar el acceso a
funciones del sistema

API RESTfull
Validar los archivos JSON
Comprobar los métodos
HTTP a utilizar
14. Requisitos de
verificación de
configuración

Un entorno de compilación seguro,

repetible y automatizable.
No utilizar componentes
desactualizados o inseguros

componentes están
actualizados
Remover características
innecesarias
Los componentes de terceros
provienen de repositorios de
confianza
Exponer solo el
comportamiento necesario

Deshabilitar el modo de
depuración en producción
No exponer información
detallada de componentes
Mensajes de error
personalizados

Encabezado en las respuestas

HTTP
Métodos HTTP utlízados por la
aplicación