Estándar de Verificación de Seguridad en Aplicaciones 3.0.1

Estndar de Verificacin de Seguridad en
Aplicaciones 3.0.1
Versin en espaol: Abril de 2017
AGRADECIMIENTOS 5
SOBRE EL ESTNDAR 5
COPYRIGHT Y LICENCIA 5
INTRODUCCIN 7
QU HAY DE NUEVO EN LA VERSIN 3.0? 7
UTILIZANDO EL ESTNDAR DE VERIFICACIN DE SEGURIDAD EN APLICACIONES 9

NIVELES DE VERIFICACIN DE SEGURIDAD DE APLICACIONES 9
CMO UTILIZAR ESTE ESTNDAR 10
APLICANDO ASVS EN LA PRCTICA 11
CASO DE ESTUDIOS 15
CASO DE ESTUDIO 1: ASVS COMO GUA DE PRUEBA DE SEGURIDAD 15
ESTUDIO DE CASO 2: UN SDLC SEGURO 16
EVALUANDO QUE EL SOFTWARE HA ALCANZADO UN NIVEL DE VERIFICACIN 18

POSTURA DE OWASP EN CERTIFICACIONES DE ASVS Y LAS MARCAS DE CONFIANZA 18
GUA PARA LAS ORGANIZACIONES CERTIFICADORAS 18
EL PAPEL DE LAS HERRAMIENTAS AUTOMTICAS DE PRUEBAS DE PENETRACIN 18
EL ROL DEL TEST DE PENETRACIN 19
COMO UNA GUA DE ARQUITECTURA DE SEGURIDAD DETALLADA 19
COMO REEMPLAZO PARA CHECKLIST DE VERIFICACIN GENERADAS POR TERCEROS 19
COMO UNA GUA PARA PRUEBAS UNITARIAS Y DE INTEGRACIN AUTOMATIZADAS 19
COMO CAPACITACIN PARA EL DESARROLLO SEGURO 20
PROYECTOS OWASP QUE UTILIZAN ASVS 21

SECURITY KNOWLEDGE FRAMEWORK 21
OWASP ZED ATAQUE PROXY (ZAP) 21
OWASP CORNUCOPIA 21
REQUISITOS DE VERIFICACIN DETALLADA 22
V1: ARQUITECTURA, DISEO Y MODELADO DE AMENAZAS 23

OBJETIVO DE CONTROL 23
REQUISITOS 23
REFERENCIAS 24
V2: REQUISITOS DE VERIFICACIN DE AUTENTICACIN 25

REQUISITOS 25
REFERENCIAS 27
V3: REQUISITOS DE VERIFICACIN DE GESTIN DE SESIONES 29

2 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

REQUISITOS 29
REFERENCIAS 30
V4: REQUISITOS DE VERIFICACIN DEL CONTROL DE ACCESO 31

REQUISITOS 31
REFERENCIAS 32
V5: REQUISITOS DE VERIFICACIN PARA MANEJO DE ENTRADA DE DATOS MALICIOSOS 33

REQUISITOS 33
REFERENCIAS 35
V6: CODIFICACIN / ESCAPE DE SALIDAS DE DATOS 37
V7: REQUISITOS DE VERIFICACIN PARA LA CRIPTOGRAFA EN EL ALMACENAMIENTO 38

REQUISITOS 38
REFERENCIAS 39
V8: REQUISITOS DE VERIFICACIN DE GESTIN Y REGISTRO DE ERRORES 40

REQUISITOS 40
REFERENCIAS 41
V9: REQUISITOS DE VERIFICACIN DE PROTECCIN DE DATOS 42

REQUISITOS 42
REFERENCIAS 44
V10: REQUISITOS DE VERIFICACIN DE SEGURIDAD DE LAS COMUNICACIONES 45

REQUISITOS 45
REFERENCIAS 46
V11: REQUISITOS DE VERIFICACIN DE CONFIGURACIN DE SEGURIDAD HTTP 48

REQUISITOS 48
REFERENCIAS 49
V12: REQUISITOS DE VERIFICACIN DE CONFIGURACIN DE SEGURIDAD 50
V13: REQUISITOS DE VERIFICACIN PARA CONTROLES MALICIOSO 51

REQUISITOS 51
REFERENCIAS 51
Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 3

V14: REQUISITOS DE VERIFICACIN DE SEGURIDAD INTERNA 52
V15: REQUISITOS DE VERIFICACIN PARA LGICA DE NEGOCIOS 53

REQUISITOS 53
REFERENCIAS 53
V16: REQUISITOS DE VERIFICACIN DE ARCHIVOS Y RECURSOS 54

REQUISITOS 54
REFERENCIAS 55
V17: REQUISITOS DE VERIFICACIN MVIL 56

REQUISITOS 56
REFERENCIAS 57
V18: REQUISITOS DE VERIFICACIN DE SERVICIOS WEB 58

REQUISITOS 58
REFERENCIAS 59
V 19. REQUISITOS DE CONFIGURACIN 60

REQUISITOS 60
REFERENCIAS 61
APNDICE A: QU SUCEDI CON 62
APNDICE B: GLOSARIO 69
ANEXO C: REFERENCIAS 73
APNDICE D: CORRELACIN CON OTRAS NORMAS 74

Agradecimientos
Sobre el estndar
El estndar de verificacin de seguridad en aplicaciones es una lista de requerimientos de

seguridad o pruebas que pueden ser utilizadas por arquitectos, desarrolladores, testers,
profesionales de seguridad e incluso consumidores, para definir tan segura es una
aplicacin.
Copyright y licencia
Copyright 2008 2017 Fundacin OWASP. Este documento es

publicado bajo licencia Creative Commons Attribution ShareAlike 3.0.
Cualquier reutilizacin o distribucin, debe dejar claro a otros los
trminos de la licencia de este trabajo.
Versin 3.0, 2015
Lderes de Proyecto Autores Lderes Revisores y Colaboradores

Andrew van der Stock Jim Manico Boy Baukema
Daniel Cuthbert Ari Kesniemi
Colin Watson
Franois-Eric Guyomarc'h
Cristinel Dumitru
James Holland
Gary Robinson
Stephen de Vries
Glenn Ten Cate
Riccardo Ten Cate
Martin Knobloch
Abhinav Sejpal
David Ryan
Steven van der Baan
Ryan Dewhurst
Raoul Endres
Roberto Martelloni
Traduccin al espaol Nicols Levin
Gerardo Canedo
Versin 2.0, 2014

Daniel Cuthbert Andrew van der Stock Antonio Fontes
Sahba Kazerooni Krishna Raja Colin Watson
Jeff Sergeant
Pekka Sillanp
Archangel Cuison
Dr Emin Tatli
Jerome Athias
Safuat Hamdy

Ari Kesniemi
Etienne Stalmans
Jim Manico
Scott Luc
Boy Baukema
Evan Gaustad
Mait Peekma
Sebastien Deleersnyder
Versin 1.0, 2009

Mike Boberski Jim Manico Andrew van der Stock
Jeff Williams Dr. Sarbari Gupta
Dave Wichers John Steven
Pierre Parrend
Barry Boyd
Dr. Thomas Braun
Ken Huang
Richard Campbell
Bedirhan Urgun
Eoin Keary
Ketan Dilipkumar Vyas
Scott Matsumoto
Colin Watson
Gaurang Shah
Liz Fong Shouvik Bardhan
Dan Cornell
George Lawless
Mandeep Khera
Stan Wisseman
Dave Hausladen
Jeff LoSapio
Matt Presson
Stephen de Vries
Theodore Winograd
Jeremiah Grossman
Nam Nguyen
Steve Coyle
Dave van Stein
John Martin
Paul Douthit
Terrie Diaz

Introduccin
Bienvenido a la versin 3.0 del Estndar de Verificacin Seguridad en Aplicaciones (ASVS por
sus siglas en ingls). El ASVS es un esfuerzo comunitario por establecer un marco de
referencia para los requisitos de seguridad, controles funcionales y no funcionales
necesarios al disear, desarrollar y testear aplicaciones web modernas.
ASVS v3.0 es la culminacin de un esfuerzo comunitario y de retroalimentacin por parte de

la industria. En esta versin, nos pareci importante estudiar las experiencias de casos de
uso del mundo real relacionados con la adopcin de ASVS. Esto ayudar a los recin llegados
al estndar planificar la adopcin de la ASVS, mientras que ayuda a las empresas existentes
aprendiendo de la experiencia de otros.
Es esperable que este estndar no genere un 100% de consenso. El Anlisis de riesgo es

siempre subjetivo hasta cierto punto, el cual crea un reto al tratar de generalizar un
estndar para todo tipo de aplicaciones. Sin embargo, esperamos que los ltimos cambios
en esta versin sean un paso hacia la direccin correcta, los cuales, de manera respetuosa,
mejoran los conceptos introducidos en este importante estndar de la industria.
Qu hay de nuevo en la versin 3.0?
En la versin 3.0, hemos aadido varias secciones nuevas, incluyendo configuracin, Web
Services, aplicaciones cliente, para hacer la norma ms aplicable a aplicaciones modernas,
comnmente responsive, con amplio uso de interfaces de usuario HTML5 o mvil, llamando
a un conjunto comn de Web Services REST, utilizando autenticacin SAML.
Hemos reducido tambin las duplicaciones en la norma, por ejemplo, para asegurarnos de
que un desarrollador mvil no necesite re-testear los mismos elementos varias veces.
Hemos proporcionado la correspondencia con el CWE (Diccionario de debilidades comunes).

Esta correspondencia utilizarse para identificar informacin tal como la probabilidad de
explotacin, consecuencia de una explotacin exitosa y en trminos generales tener la
visin de lo que podra salir mal si un control de seguridad no se utiliza o no se aplican
eficazmente para mitigar la debilidad.
Por ltimo, buscamos ayuda en la comunidad con el fin de generar sesiones para la revisin
por pares durante las conferencias de AppSec EU 2015 y una sesin final de trabajo en
AppSec USA 2015 con el fin de incluir una enorme cantidad de comentarios de la
comunidad. Durante la revisin, si el significado de un control fue cambi sustancialmente,
se cre un nuevo control dejando el antiguo como obsoleto. Hemos deliberadamente
optado por no volver a utilizar los requisitos de control obsoletos, ya que podra ser una
fuente de confusin. Hemos proporcionado una asignacin completa de lo que ha cambiado
en el apndice A.

Tomados en conjunto, la versin numero 3.0 contiene el cambio ms grande historia del
estndar. Esperamos que le sea til la actualizacin de la norma y que lo utilice en formas
que slo podemos imaginar.

Utilizando el Estndar de Verificacin de Seguridad en Aplicaciones
ASVS tiene dos objetivos principales:
ayudar a las organizaciones en el desarrollo y mantenimiento aplicaciones seguras

permitir la alineacin entre las necesidades y ofertas de los servicios de seguridad,
proveedores de herramientas de seguridad y consumidores
Niveles de verificacin de seguridad de aplicaciones
El Estndar de Verificacin de Seguridad en Aplicaciones define tres niveles de verificacin

de seguridad, incrementando la profundidad con cada nivel.
ASVS nivel 1 se encuentra dirigido a todo tipo de software.

ASVS nivel 2 es para aplicaciones que contienen datos sensibles, que requieren
proteccin.
ASVS nivel 3 es para las aplicaciones ms crticas - aplicaciones que realizan
transacciones de alto valor, contienen datos mdicos confidenciales, o cualquier
aplicacin que requiera el ms alto nivel de confianza.
Cada nivel ASVS contiene una lista de requerimientos de seguridad. Cada uno de estos
requisitos pueden tambin corresponderse a funcionalidades especficas de seguridad y
capacidades que deben construirse por los desarrolladores de software.
Figura 1 Niveles del Estndar de Verificacin de Seguridad en Aplicaciones de OWASP

Cmo utilizar este estndar
Una de las mejores maneras de emplear el Estndar de Verificacin de Seguridad en

Aplicaciones es utilizarlo como checklist de seguridad especfica para su aplicacin,
plataforma u organizacin. Ajustar el ASVS a sus casos de uso le ayudar aumentar el foco
en los requisitos de seguridad ms importantes para sus proyectos y entornos.
Nivel 1: Oportunista
Una aplicacin alcanza ASVS nivel 1 (u oportunista) si se defiende adecuadamente contra

vulnerabilidades de seguridad de aplicaciones que son fciles de descubrir y se incluyen en
el OWASP Top 10 u otras listas similares.
Este nivel es apropiado tpicamente para aplicaciones donde se requiere escasa confianza
en el uso correcto de los controles de seguridad, o para proporcionar un anlisis rpido a un
conjunto de aplicaciones de una organizacin, o asistir en la elaboracin de una lista de
requerimientos de seguridad con prioridades como parte de un esfuerzo de mltiples fases.
Los controles de nivel 1 pueden ser asegurados automticamente por herramientas o
manualmente sin acceso al cdigo fuente. Consideramos a nivel 1 como el mnimo
requerido para todas las aplicaciones.
Las amenazas a la aplicacin probablemente provendrn de atacantes que utilizan tcnicas

simples y de bajo esfuerzo para identificar vulnerabilidades fciles de encontrar y de
explotar. Esto es en contraste con un ataque dirigido el cual se enfocar especficamente a
la aplicacin. Si los datos procesados por la aplicacin tienen un alto valor, difcilmente sea
suficiente con una revisin de nivel 1.
Nivel 2: Estndar
Una aplicacin alcanza ASVS nivel 2 (o estndar), si se defiende adecuadamente contra la

mayora de los riesgos asociados con el software de hoy en da.
El Nivel 2 asegura que controles de seguridad se encuentran en el lugar adecuado, son

efectivos y son utilizados dentro de la aplicacin. Este nivel es generalmente apropiado para
aplicaciones que manejan transacciones business-to-business, informacin de salud,
implementan funciones sensibles o crticas para el negocio o incluyen el proceso de otros
activos sensibles.
Las amenazas para aplicaciones de nivel 2 por lo general estn motivados por atacantes los
cuales se centran en objetivos concretos, utilizando herramientas y tcnicas efectivas en el
descubrimiento y explotacin de vulnerabilidades dentro de las aplicaciones.
Nivel 3: Avanzado
El nivel 3 en ASVS es el ms alto nivel de verificacin dentro de ASVS. Este nivel est
reservado normalmente para aplicaciones que requieren niveles significativos de

verificacin de seguridad, como las que se encuentran dentro de reas de militares, salud,
seguridad, infraestructuras, etc. Las organizaciones pueden requerir del nivel 3 para
aplicaciones que realizan funciones crticas, donde una falla de seguridad podra afectar
significativamente sus operaciones y hasta su supervivencia. Un ejemplo en la aplicacin del
nivel 3 de ASVS se proporciona a continuacin. Una aplicacin alcanza el nivel 3 (o
avanzado) si se defiende adecuadamente contra vulnerabilidades de seguridad avanzadas y
tambin demuestra los principios de un buen diseo de seguridad.
Una aplicacin en el nivel 3 de ASVS, requiere un anlisis de mayor profundidad,

arquitectura, codificacin y Testing en todo nivel. Una aplicacin segura es modularizada de
forma significativa (para facilitar por ejemplo su resiliencia, escalabilidad, y sobre todo,
capas de seguridad), y cada mdulo (separados por conexiones de la red o instancias fsicas)
se encarga de sus responsabilidades de seguridad (defensa en profundidad) la que debe ser
debidamente documentada. Las responsabilidades incluyen controles para asegurar la
confidencialidad (cifrado, por ejemplo), integridad (transacciones, validacin de la entrada),
disponibilidad (manejo de carga), autenticacin (incluyendo autenticacin entre sistemas),
no repudio, autorizacin y auditora (bitcoras).
Aplicando ASVS en la prctica
Diferentes amenazas poseen diferentes motivaciones. Algunas industrias tienen activos de

informacin nicos y valiosos y deben cumplir regulaciones y normas especficas de dichas
industrias.
A continuacin, se proporcionan recomendaciones con respecto a los niveles de ASVS

especficas para algunas industrias.
Aunque existen criterios nicos y diferencias en las amenazas para cada sector, una
amenaza comn a todos los segmentos o industrias, son los ataques oportunistas. Estos
buscarn cualquier aplicacin vulnerable fcilmente explotable. Por esta razn el nivel 1 se
recomienda para toda aplicacin. Se sugiere este punto de partida para manejar los riesgos
ms fciles de encontrar. Tambin se recomienda a las organizaciones observar
detenidamente sus riesgos especficos basados en la naturaleza de su negocio.
Por otro lado, el nivel 3 de ASVS se encuentra reservado para aquellos casos en que se
podra poner en peligro la seguridad humana o cuando una violacin a la aplicacin podra
impactar seriamente y por completo a la organizacin.

Industria Perfil de amenaza L1 Recomendacin L2 Recomendacin L3 Recomendacin
Financiera y Aunque este segmento Todas las aplicaciones Aplicaciones que Aplicaciones que
Seguros experimentar intentos de atacantes accesibles desde la contienen informacin contengan grandes
oportunistas, a menudo es visto red. sensible como nmeros cantidades de
como un objetivo de alto valor por de tarjeta de crdito, informacin sensible
atacantes motivados y los ataques se informacin personal, o que permiten que
deben muy a menudo a motivos que puede mover una sea rpido la
financieros. Comnmente, los cantidad limitada de transferencia de
atacantes buscan datos o dinero de manera grandes sumas de
credenciales de la cuenta que pueden limitada. Los ejemplos dinero (p. ej.
utilizar para cometer fraudes o incluyen: transferencias) o
beneficiarse directamente (i) transferir dinero entre transferencia de
aprovechando la funcionalidad de cuentas en la misma grandes sumas de
flujo de dinero en aplicaciones. Las institucin o dinero en forma de
tcnicas incluyen a menudo (ii) una forma ms lenta transacciones
credenciales robadas, ataques a nivel del movimiento de dinero individuales o como
de aplicacin y la ingeniera social. (por ejemplo, ACH) con un lote de
Algunas consideraciones importantes lmites de transaccin o transferencias
de cumplimiento incluyen EL (iii) transferencias en pequeas.
ESTNDAR PCI DSS (PCI DSS), Gramm lnea con lmites de
Leech Bliley Act y Sarbanes-Oxley transferencia dentro de
(SOX). un perodo de tiempo.

Manufacture Estas industrias no parecen tener Todas las aplicaciones Aplicaciones que Aplicaciones que
ra, mucho en comn, pero los agentes accesibles desde la contienen informacin contiene valiosa
profesional, de amenaza que suelen atacar a las red. interna o informacin propiedad
transporte, organizaciones en este segmento son sobre empleados que intelectual, secretos
tecnologa, ms propensos a realizar ataques pueden aprovecharse comerciales o
utilidades, enfocados con ms tiempo, habilidad utilizando la ingeniera secretos del
infraestructu y recursos. A menudo la informacin social. Aplicaciones que gobierno (p. ej. en
ra y defensa sensible o los sistemas no son fciles contiene informacin los Estados Unidos
de localizar y requieren utilizar o poco esencial, pero de esto puede ser
manipular individuos que trabajen importante propiedad cualquier cosa
dentro de la organizacin, utilizando intelectual o secretos clasificados en
tcnicas de ingeniera social. Los comerciales. secreto o superior)
ataques pueden involucrar individuos que es fundamental
que trabajan dentro de la para la supervivencia
organizacin, extraos a la o el xito de la
organizacin, o una combinacin de organizacin.
ambos. Sus objetivos pueden incluir Aplicaciones que
acceso a la propiedad intelectual para controlan
obtener ventajas estratgicas o funcionalidad
tecnolgicas. Tampoco queremos sensible (p. ej.
pasar por alto a los atacantes que transporte,
buscan abusar la funcionalidad de la fabricacin de
aplicacin para influenciar el equipos, sistemas de
comportamiento de la aplicacin o control) o que tienen
alterar sistemas sensibles. la posibilidad de
La mayora de los atacantes buscan amenazar la
informacin sensible que puede ser seguridad
utilizada directa o indirectamente
para beneficiarse al incluir datos
personales a la informacin de pago.
A menudo los datos pueden utilizarse
para una variedad de esquemas de
fraude, robo de identidad o pagos
fraudulentos.

Salud La mayora de los atacantes est Todas las aplicaciones Aplicaciones con Aplicaciones
buscando informacin sensible que accesibles desde la cantidades pequeas o utilizadas para el
puede ser utilizada directa o red moderadas de control de equipos
indirectamente para beneficiarse al informacin mdica mdicos,
incluir datos personales a la confidencial (informacin dispositivos o
informacin de pago. A menudo los de salud protegida), registros que
datos pueden utilizarse para una informacin de pueden poner en
variedad de esquemas de fraude, identificacin personal o peligro la vida
robo de identidad y pagos datos de pago. humana. Sistemas
fraudulentos. de pago de Punto de
venta y (POS) que
Para Los Estados Unidos existen el contienen grandes
Health Insurance Portability and cantidades de datos
Accountability Act (HIPAA) de transacciones que
http://www.hhs.gov/ocr/privacy/ podran ser
utilizados para
cometer fraudes.
Esto incluye las
interfaces
administrativas de
estas aplicaciones
Venta por Muchos de los atacantes en este Todas las aplicaciones Adecuado para Sistemas de pago de
menor, segmento utilizan tcticas accesibles desde la aplicaciones de negocios, Punto de venta y
alimento, oportunistas de "aplaste y agarre". red. Catlogo de la (POS) que contienen
hospitalidad Sin embargo, tambin existe una informacin del producto, grandes cantidades
amenaza regular de ataques informacin corporativa de datos de
especficos en aplicaciones que interna y aplicaciones con transacciones que
contienen informacin de pagos, que informacin limitada del podran ser
realizan transacciones financieras o usuario (p. ej. utilizados para
almacenan informacin personal que informacin de contacto). cometer fraudes.
pueda ser identificable. Aunque Aplicaciones con Esto incluye las
menos probable que las amenazas cantidades pequeas o interfaces
antes mencionadas, tambin existe la moderadas de la administrativas de
posibilidad de amenazas ms funcionalidad de datos o estas aplicaciones.
avanzadas las cuales atacan a este de comprobacin de Aplicaciones con un
segmento de la industria para robar pago. gran volumen de
propiedad intelectual, obtener informacin sensible
inteligencia competitiva o ganar una como nmeros de
ventaja con la organizacin la cual se tarjeta de crdito,
ha atacado o de un socio en nombres completos,
negociaciones. documentos de
indentidad, etc.

Caso de estudios
Caso de Estudio 1: ASVS como gua de prueba de seguridad
En una Universidad privada en Utah, Estados Unidos, el equipo rojo del campus utiliza el
OWASP ASVS como gua al realizar tests de penetracin a aplicaciones. Es utilizado a lo largo
del proceso de pruebas, desde la planificacin inicial, definiendo reuniones de orientacin
para las actividades de la prueba y como una manera de enmarcar las conclusiones del
informe final entregado a los clientes. El equipo rojo tambin organiza capacitaciones para
el equipo utilizando el ASVS.
El equipo rojo del Campus realiza tests de penetracin de redes y aplicaciones para varios
departamentos del campus como parte de la estrategia de seguridad de la informacin
general de la Universidad. Durante las reuniones de planificacin iniciales, los clientes
suelen ser reticentes a dar autorizacin para que su aplicacin sea puesta a prueba por un
equipo de estudiantes. Al presentar el ASVS y explicando a los interesados que las
actividades de pruebas son guiadas por esta estndar, y que el informe final incluir cmo
se comporta la aplicacin en comparacin con el estndar, muchas preocupaciones quedan
inmediatamente aclaradas. Luego, el ASVS es utilizado durante la evaluacin para ayudar a
determinar cunto tiempo y esfuerzo se utilizar en la prueba. Mediante el uso de los
niveles de verificacin predefinidas de la ASVS, el equipo rojo explica el enfoque basado en
riesgo de las pruebas a realizar. Esto ayuda al cliente, los actores y el equipo para llegar a un
acuerdo sobre un alcance apropiado para la aplicacin en cuestin.
Una vez que el test comienza, el equipo rojo utiliza el ASVS para organizar actividades y
dividir la carga de trabajo. Al realizar el seguimiento de los requisitos de verificacin que han
sido probados y que se encuentran pendientes, el gerente de proyecto para el equipo puede
observar fcilmente el avance de las pruebas. Esto conduce a mejorar la comunicacin con
los clientes y permite al jefe de proyecto gestionar mejor los recursos. Dado que el equipo
rojo est compuesto principalmente de estudiantes, la mayora de los miembros del equipo
tienen mltiples demandas de su tiempo proveniente de diferentes cursos. Las tareas bien
definidas, basadas en los requisitos de verificacin individual o categoras totales, ayudan a
los miembros del equipo a saber exactamente qu debe analizarse y que estos puedan
proporcionar estimaciones precisas sobre cunto tiempo tardarn para completar las
tareas. La actividad de informar tambin se beneficia de la clara organizacin del ASVS,
debido a que los miembros del equipo pueden reportar sus hallazgos antes de continuar
con el siguiente punto del estndar, generando el informe de forma simultnea con la
ejecucin de las pruebas de penetracin.
El equipo rojo organiza el informe final alrededor de la ASVS, informando del estado de cada
requisito de verificacin y proporcionando ms detalles cuando sea apropiado. Esto le da
una idea a clientes e interesados de cmo se encuentra su aplicacin con respecto al
estndar, lo cual es extremadamente valioso desde el punto de vista del seguimiento pues
permite ver cmo ha mejorado o empeorado la seguridad durante un transcurso de tiempo.

Adems, los actores interesados en cmo la aplicacin se comporta en una categora
especfica o categoras pueden encontrar fcilmente dado que el formato del informe se
alinea con el formato del ASVS. La estructura del ASVS tambin facilita el entrenamiento de
nuevos miembros del equipo sobre cmo escribir un informe comparando el formato con el
informe anterior.
Finalmente, el entrenamiento del equipo rojo ha mejorado con la adopcin del ASVS.
Anteriormente, los entrenamientos semanales se centraban sobre un tema elegido por el
equipo o gerente del proyecto. stos eran seleccionados basados en las peticiones de los
miembros del equipo y las necesidades percibidas. La formacin basada en estos criterios
tena el potencial de ampliar las habilidades de los miembros del equipo, pero no
necesariamente se relacionaban con las actividades bsicas del equipo rojo. En otras
palabras, el equipo no consigua mejorar significativamente en pruebas de penetracin.
Despus de adoptar el ASVS, el entrenamiento del equipo, se centra ahora en cmo probar
los requisitos de verificacin individual. Esto ha llevado a una mejora significativa y medible
en las habilidades de los miembros individuales del equipo y la calidad de los informes
finales.
Estudio de caso 2: un SDLC seguro
Un emprendimiento "start-up" que busca proporcionar anlisis de grandes datos a

instituciones financieras reconoce que implementar seguridad durante el desarrollo de su
aplicacin es una de las prioridades ms altas de la lista de requisitos para acceder y
procesar meta-datos financieros. En este caso, la Compaa "start-up" ha optado por utilizar
el ASVS como base de su ciclo de desarrollo gil.
La compaa "start-up" utiliza el ASVS para generar casos de uso e historias para cuestiones
de seguridad funcional, tales como la mejor manera de implementar la funcionalidad para
iniciar la sesin en la aplicacin. La compaa "start-up" usa ASVS de forma diferente en
comparacin a la mayora - ellos tratan de ver a travs de ASVS, recogiendo los requisitos
que se adhieren al sprint actual, y lo agregan directamente a la acumulacin del sprint si es
un requisito funcional, o como una limitacin a casos de uso existentes si no son
funcionales. Por ejemplo, la adicin de la autenticacin TOTP (Contrasea de un solo uso
basada en tiempo), junto con las polticas de contraseas y servicio web que de deteccin
de ataques de fuerza bruta. En los sprints futuros, los requisitos adicionales se seleccionarn
basados en el criterio "justo a tiempo", o que "no se va a necesitar".
Los desarrolladores utilizan el ASVS como una checklist de revisin por pares, lo que ayuda a
que cdigo inseguro no sea ingresado en el repositorio, y en retrospectiva, desafiar a los
desarrolladores que hayan ingresado algn cdigo en el repositorio que contenga una nueva
caracterstica, que hayan considerado los requisitos del ASVS y si hay algo se puede mejorar
o reducir en los sprints futuros.
Por ltimo, los desarrolladores utilizan la ASVS como parte de su unidad de seguridad de
verificacin automatizada y conjuntos de pruebas de integracin, casos de abuso y casos de

prueba a travs de "fuzzing". El objetivo es reducir el riesgo de la "metodologa de catarata"
el cual pone el "test de penetracin al final" causando costosos esfuerzos de re-factorizacin
de cdigo cuando se deben entregar ciertas metas dentro del sistema. Como podran
promoverse nuevas caractersticas del software despus de cada sprint, no es suficiente
confiar en una actividad nica de aseguramiento. As, mediante la automatizacin de las
pruebas, no debera haber cuestiones de suma importancia que puedan ser encontradas por
un pentester calificado con tan solo semanas para probar la aplicacin.

Evaluando que el software ha alcanzado un nivel de verificacin
Postura de OWASP en certificaciones de ASVS y las marcas de confianza
OWASP, como organizacin independiente sin fines de lucro, no certifica proveedores,

verificadores ni software.
Tales afirmaciones de aseguramiento, sellos de confianza o certificaciones no son

oficialmente validadas, registradas o certificadas por OWASP, por lo tanto, una organizacin
que cuenta con ese punto de vista debe ser cautelosa en depositar su confianza en
cualquier tercero o sello de confianza que clame que tiene una certificacin de ASVS.
Esto no debe inhibir organizaciones para ofrecer dichos servicios de garanta, con tal de que
no pretendan proveer una certificacin oficial de OWASP.
Gua para las organizaciones certificadoras
El estndar de verificacin de seguridad en aplicaciones puede ser utilizado como un libro

abierto de verificacin para la aplicacin, en conjunto con el acceso abierto y sin
restricciones a arquitectos y desarrolladores, documentacin de proyectos, cdigo fuente,
acceso autenticado al sistema (incluyendo por lo menos una cuenta en cada rol),
particularmente para las verificaciones de nivel 2 y 3.
Histricamente, los test de penetracin y las revisiones de cdigo han incluido hallazgos
por excepcin. es decir, el informe final solo se compone de defectos de seguridad. Una
organizacin certificadora debe incluir en cualquier informe cual fue el alcance de la
verificacin (especialmente si un componente clave est fuera de alcance, como la
autenticacin SSO), un resumen de resultados de la verificacin, incluyendo las pruebas
exitosas y las fallidas, con indicaciones claras de cmo resolver las fallidas.
Una prctica estndar en la industria es mantener papeles de trabajo detallados, imgenes

o videos, registros electrnicos de las pruebas, registros proxy y notas asociadas como un
script de limpieza. Pueden ser realmente tiles como pruebas de los hallazgos para la
mayora de los desarrolladores que tengan dudas. No es suficiente con ejecutar una
herramienta e informar sobre de las fallas; Esto no (en absoluto) proporciona suficiente
evidencia que todos los problemas han sido probados a un nivel de certificacin y que estos
se hayan comprobado completamente. En caso de controversia, debe existir prueba
suficiente que garantice demostrar que cada requisito verificado de hecho ha sido probado.
El papel de las herramientas automticas de pruebas de penetracin
Las herramientas automatizadas buscan brindar la mayor cobertura posible y ejecutar

tantos parmetros como sea posible con varias formas de entradas maliciosas.

No es posible completar totalmente la verificacin ASVS utilizando solamente herramientas
automticas. Mientras que una gran mayora de los requisitos en el nivel 1 se pueden
verificar por medio de pruebas automatizadas, la mayora no lo son.
Se debe de tener en cuenta que a medida que madura la industria de la seguridad en

aplicaciones, la lnea entre pruebas automatizadas y manuales se torna borrosa. Las
herramientas automatizadas son a menudo adaptadas manualmente por expertos para
realidades puntuales.
El rol del test de penetracin
Es posible realizar una prueba de penetracin manual y verificar todos los puntos del nivel
L1 sin necesidad de acceso al cdigo fuente, aunque esta no es una prctica muy utilizada.
Para el nivel L2 se requiere al menos algn acceso a los desarrolladores, documentacin,
cdigo y acceso autenticado al sistema. Una cobertura completa de pruebas de penetracin
del nivel 3 no es posible, como la mayora de los problemas adicionales incluyen revisin de
configuracin del sistema, revisin de cdigo malicioso, modelado de amenazas y otros
artefactos de prueba de penetracin.
Como una gua de arquitectura de seguridad detallada
Uno de los usos ms comunes para el estndar de verificacin de seguridad en aplicaciones

es su utilizacin como un recurso para arquitectos de seguridad. Los dos marcos de la
arquitectura de seguridad, SABSA o TOGAF, carecen de una gran cantidad de informacin
necesaria para completar por medio de una revisin de arquitectura aspectos de seguridad
de la aplicacin. ASVS puede utilizarse mitigar esas carencias permitiendo a los arquitectos
de seguridad elegir controles adecuados para problemas comunes, tales como patrones de
proteccin de datos y estrategias de validacin de entradas de datos.
Como reemplazo para checklist de verificacin generadas por terceros
Muchas organizaciones pueden beneficiarse de la adopcin del ASVS, eligiendo uno de los
tres niveles, o utilizar ASVS y refinar nicamente lo que se requiere para cada nivel de riesgo
de la aplicacin en un dominio especfico. Recomendamos este tipo de combinacin o
adaptacin del ASVS original mientras se mantiene la trazabilidad, por lo que si una
aplicacin ha pasado requisito 4.1, esto significa lo mismo tanto para el refinamiento como
para el estndar a medida que ste evolucione.
Como una gua para pruebas unitarias y de integracin automatizadas
El ASVS est diseado para ser altamente verificable, con la sola excepcin de requisitos de
arquitectnicos y de cdigo malicioso. A travs de la generacin de pruebas unitarias y de
integracin (tanto especficas como de fuzzing), la aplicacin se aproxima a auto verificase y
validarse con cada construccin. Por ejemplo, se pueden generar pruebas adicionales para
el paquete de pruebas para el control de acceso, para testear el parmetro nombre de
usuario para nombres de usuario comunes, enumeracin de cuenta, ataques de fuerza
bruta, inyeccin LDAP y SQL y XSS. Asimismo, se deben incluir pruebas al parmetro de
contrasea para las ms comunes, su longitud, inyeccin de byte nulo, eliminacin del
parmetro, XSS, enumeracin de cuentas y mucho ms.
Como capacitacin para el desarrollo seguro
ASVS tambin puede utilizarse para definir caractersticas de software seguro. Muchos
cursos de codificacin segura son simplemente cursos ticos de hacking con un ligero
toque de consejos sobre codificacin. Esto no ayuda a los desarrolladores de sistemas. En
cambio, cursos de desarrollo seguro pueden usar la gua ASVS con un fuerte enfoque en los
controles pro-activos en esta, en lugar de cosas negativas del OWASP Top 10.

Proyectos OWASP que utilizan ASVS
Security Knowledge Framework
https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework
Para entrenar desarrolladores en la escritura de cdigo seguro - El proyecto SKF es una
aplicacin completamente gratis escrita en Python-Flask que utiliza el estndar de
verificacin de seguridad OWASP para aplicaciones, pensada para entrenar en la escritura
de cdigo seguro desde su diseo.
OWASP Zed ataque Proxy (ZAP)
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
OWASP Zed (ZAP) es una herramienta de fcil uso e integrada para la bsqueda de
vulnerabilidades en aplicaciones web. Est diseada tanto para ser utilizado por personas
con amplia experiencia en seguridad, as como desarrolladores y testers funcionales que son
nuevos en pruebas de penetracin. ZAP ofrece escaneos automatizados e integra un
conjunto de herramientas que permiten encontrar vulnerabilidades de seguridad
manualmente.
OWASP Cornucopia
https://www.owasp.org/index.php/OWASP_Cornucopia
Cornucopia de OWASP es un mecanismo en forma de un juego de cartas que ayudar a
equipos de desarrollo de software a identificar requisitos de seguridad utilizado
metodologas giles y procesos de desarrollo formales. Es un lenguaje agntico de la
tecnologa y la plataforma. El contenido de Cornucopia fue seleccionado en base a la
estructura de la Gua Prctica de Codificacin Segura de OWASP - gua de referencia rpida
(SCP), considerando adicionalmente el estndar de verificacin de seguridad de OWASP
para aplicaciones, la gua de pruebas de OWASP y los principios de programacin segura de
David Rook.

Requisitos de verificacin detallada
V1. Arquitectura, diseo y modelado de amenazas
V2. Autenticacin
V3. Gestin de sesiones
V4. Control de acceso
V5. Manejo de entrada de datos maliciosos
V7. Criptografa en el almacenamiento
V8. Gestin y registro de errores
V9. Proteccin de datos
V10. Comunicaciones
V11. Configuracin de seguridad HTTP
V13. Controles Maliciosos
V15. Lgica de negocio
V16. Archivos y recursos
V17. Mvil
V18. Servicios Web (Nuevo en 3.0)
V19. Configuracin (nuevo en 3.0)

V1: Arquitectura, diseo y modelado de amenazas
Objetivo de control
Asegurar que una aplicacin verificada satisfaga los siguientes requisitos de alto nivel:
Nivel 1, los componentes de la aplicacin son identificados y tienen una razn de ser.
Nivel 2, se ha definido la arquitectura y el cdigo se adeca a sta.
Nivel 3, la arquitectura y el diseo son los indicados, se utilizan y resultan eficaces.
Nota: Esta seccin se ha introducido nuevamente en la versin 3.0, pero se utilizan en

esencia los mismos controles arquitectnicos de la versin 1.0 del ASVS.
Requisitos
# Descripcin 1 2 3 Desde
Verificar que todos los componentes de la aplicacin se

1.1 1.0
encuentran identificados y asegurar que son necesarios.
Verificar todos los componentes, tales como bibliotecas,

mdulos y sistemas externos, que no son parte de la
1.2 1.0
aplicacin pero que la misma los necesita para funcionar se
han identificado.
Verificar que se ha definido una arquitectura de alto nivel

1.3 1.0
para la aplicacin.
Verificar que todos los componentes de la aplicacin se

1.4 definen de acuerdo a las funciones de negocio o de 1.0
seguridad que proporcionan.
Verificar que todos los componentes que no son parte de la

aplicacin pero que son necesarios para su
1.5 1.0
funcionamiento, sean definidos de acuerdo a las funciones
de negocio o de seguridad que proporcionan.
Verificar que se ha realizado un modelo de amenazas para

la aplicacin en cuestin y que ste cubre riesgos asociados
1.6 con la suplantacin de identidad, manipulacin, repudio, 1.0
revelacin de informacin y elevacin de privilegios
(STRIDE).
Verificar que todos los controles de seguridad (incluyendo

1.7 las bibliotecas que llaman a servicios de seguridad 3.0
externos) tienen una implementacin centralizada.
1.8 Verificar que los componentes estn separados unos de 3.0

otros mediante controles de seguridad, tales como
segmentacin de la red, reglas de firewall, o grupos de
seguridad basados en la nube.
Verificar que la aplicacin tiene una clara separacin entre

la capa de datos, la capa de control y la capa de
1.9 3.0
presentacin, tal que las decisiones de seguridad pueden
aplicarse en sistemas confiables.
Verificar que no hay ninguna lgica de negocio sensible,

1.10 claves secretas u otra informacin propietaria en el cdigo 3.0
del lado del cliente.
Verificar que todos los componentes de la aplicacin,

bibliotecas, mdulos, frameworks, plataformas y sistemas
1.11 3.0.1
operativos se encuentran libres de vulnerabilidades
conocidas
Referencias
Para obtener ms informacin, consulte:
Cheat Sheet de Modelado de Amenazas

https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet
Cheat Sheet de Anlisis de Superficie de ataque
https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet

V2: Requisitos de verificacin de autenticacin
Objetivo de control
Autenticacin es el acto de establecer o confirmar, algo (o alguien) como autntico, esto es,
que lo que reclama sobre aquello es verdadero. Se debe asegurar que la aplicacin satisface
los siguientes requisitos de alto nivel:
Verifica la identidad digital del remitente de una comunicacin.

Asegura que slo los usuarios autorizados son capaces de autenticarse y que las
credenciales sean transportadas de forma segura.
Requisitos
2.1 Verificar que todas las pginas y recursos requieran

autenticacin excepto aquellos que sean especficamente 1.0
destinados a ser pblicos (Principio de mediacin completa).
2.2 Verificar que todos los campos de credenciales no reflejen

las contraseas del usuario. Cargar la credencial por parte
de la aplicacin implica que la misma fue almacenada de 3.0.1
forma reversible o en texto plano, lo que se encuentra
explcitamente prohibido.
2.4 Verificar que todos los controles de autenticacin se

1.0
realicen del lado del servidor.
2.6 Verificar que los controles de autenticacin fallan de forma

segura para evitar que los atacantes no puedan iniciar 1.0
sesin.
2.7 Verificar que los campos de contraseas permiten o

fomentan el uso de frases como contraseas (passphrases) y 3.0.1
no impiden el uso de gestores de contraseas, contraseas
largas o altamente complejas.
2.8 Verificar que toda funcin relacionada con la autenticacin

(como registro, actualizacin del perfil, olvido de nombre de
usuario, recuperacin de la contrasea, token perdido /
deshabilitado, funciones de help desk o IVR) que pueda ser 2.0
utilizada de forma indirecta como mecanismo de
autenticacin, sea al menos tan resistente a ataques como
el mecanismo primario.

2.9 Verificar que la funcionalidad de cambio de contrasea

solicite la contrasea anterior, la nueva contrasea y una 1.0
confirmacin de la contrasea.
2.12 Verificar que todas las decisiones de autenticacin son

registradas en la bitcora sin almacenar informacin sobre
la contrasea o el identificador de la sesin. Esto debera 3.01
incluir los metadatos necesarios para investigaciones de
seguridad.
2.13 Verificar que las contraseas de las cuentas se encuentren

almacenadas utilizando una rutina de hashing con una sal, y 3.0.1
que requiera un factor de trabajo lo suficientemente alto
para evitar un ataque de fuerza bruta.
2.16 Verificar que las credenciales son transportadas mediante

un enlace cifrado adecuadamente y que todas las 3.0
pginas/funciones que requieren que el usuario introduzca
credenciales se realicen utilizando enlaces cifrados.
2.17 Verificar que las funciones de recuperar contrasea y acceso

no revelen la contrasea actual y que la nueva contrasea 2.0
no se enve en texto plano al usuario.
2.18 Verificar que no es posible enumerar informacin mediante

las funcionalidades de: inicio de sesin, reinicio o 2.0
recuperacin contraseas.
2.19 Verificar que no se utilizan contraseas por defecto en la

aplicacin o cualquiera de los componentes utilizados por la 2.0
misma (como "admin/password").
2.20 Verificar que existen mecanismos de anti-automatizacin

que previenen la verificacin de credenciales obtenidas de 3.0.1
forma masiva, ataques de fuerza bruta y ataques de
bloqueos de cuentas.
2.21 Verificar que todas las credenciales de autenticacin para

acceder a servicios externos a la aplicacin se encuentran 2.0
cifradas y almacenadas en un lugar protegido.
2.22 Verificar que las funcionalidades de recuperar contrasea y

otras formas de recuperar la cuenta utilizan mecanismos de
TOTP (Time-Based One-Time Password) u otro tipo de soft
token, push a dispositivo mvil u otro tipo de mecanismo de 3.0.1
recuperacin offline. El uso de un valor aleatorio en un
correo electrnico o SMS debe ser la ltima opcin ya que
son conocidas sus debilidades.

2.23 Verificar que el bloqueo de la cuenta se divida en estado de

bloqueo suave y duro, y stas no son mutuamente
excluyentes. Si una cuenta est temporalmente bloqueada 3.0
de forma suave debido a un ataque de fuerza bruta, esto no
debe restablecer el bloqueo de estado duro.
2.24 Verificar que si la aplicacin hace uso de conocimiento

basado en preguntas (tambin conocido como "secreto"),
las preguntas no violan leyes de privacidad y son lo 3.0.1
suficientemente fuertes para proteger la cuenta de
recuperaciones maliciosas.
2.25 Verificar que el sistema puede configurarse para no permitir

el uso de un nmero de contraseas utilizadas 2.0
anteriormente.
2.26 Verificar que la re-autenticacin basada en riesgo,

autenticacin de dos factores o firma de transacciones se 3.0.1
encuentra implementada en los lugares adecuados.
2.27 Verificar que existen medidas para bloquear el uso de 3.0

contraseas comnmente utilizadas y contraseas dbiles.
2.28 Verificar que todos los desafos de autenticacin, ya sea 3.0

exitosa o fallida, responden en el mismo tiempo promedio.
2.29 Verificar que secretos, llaves de API y contraseas no se

incluyen en el cdigo fuente o en los repositorios en lnea de 3.0
cdigo fuente.
2.31 Verificar que, si una aplicacin permite a los usuarios

autenticarse, puedan hacerlo mediante autenticacin de
dos factores u otra autenticacin fuerte, o cualquier 3.0
esquema similar que proporcione proteccin contra la
divulgacin de nombres de usuario y contraseas.
2.32 Verificar que las interfaces administrativas de la aplicacin

3.0
no sean accesibles a intrusos.
2.33 Autocompletar de navegadores e integracin con gestores

de contraseas deben estar permitidos a no ser que se 3.0.1
encuentren prohibidos por polticas de riesgos.
Referencias

Gua de pruebas OWASP 4.0: Prueba de autenticacin
https://www.owasp.org/index.php/Testing_for_authentication
Cheat Sheet - Almacenamiento de Contrasea
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Cheat sheet - Olvido de Contrasea
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
Escoger y usar preguntas de seguridad
https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat
_Sheet

V3: Requisitos de verificacin de gestin de sesiones
Objetivo de control
Uno de los componentes bsicos de cualquier aplicacin web es el mecanismo por el cual
controla y mantiene el estado de un usuario al interactuar con sta. Esto se refiere a manejo
de sesiones y se define como el conjunto de todos los controles que rigen el estado
completo de interaccin entre un usuario y la aplicacin basada en la web.
Se debe asegurar que la aplicacin verificada satisface los siguientes requerimientos de

manejo de sesiones de alto nivel:
Las sesiones son nicas para cada individuo y no conjeturadas o compartidas

Las sesiones son invalidadas cuando ya no son necesarias y el tiempo es limitado
durante los perodos de inactividad.
Requisitos
3.1 Verificar que no se utiliza un gestor de sesiones

personalizado, o que, si el gestor de sesiones es
1.0
personalizado, ste sea resistente contra los ataques ms
comunes.
3.2 Verificar que las sesiones se invalidan cuando el usuario

1.0
cierra la sesin.
3.3 Verificar que las sesiones se invalidan luego de un

1.0
perodo determinado de inactividad.
3.4 Verificar que las sesiones se invalidan luego de un

perodo determinado de tiempo, independientemente de 1.0
que se est registrando actividad (timeout absoluto).
3.5 Verificar que todas las pginas que requieren

autenticacin poseen acceso fcil y visible a la 1.0
funcionalidad de cierre de sesin.
3.6 Verificar que el identificador de sesin nunca se revele en

URLs, mensajes de error o registros de bitcora. Esto
1.0
incluye verificar que la aplicacin no es compatible con la
re-escritura de URL incluyendo el identificador de sesin.
3.7 Verificar que toda autenticacin exitosa y re-

autenticaciones generen un nuevo identificador de 1.0
sesin.

3.10 Verificar que slo los identificadores de sesin generados
1.0
por la aplicacin son reconocidos como activos por sta.
3.11 Verificar que los identificadores de sesin son

suficientemente largos, aleatorios y nicos para las 1.0
sesiones activas.
3.12 Verificar que los identificadores de sesin almacenados

en cookies poseen su atributo path establecido en un
3.0
valor adecuadamente restrictivo y que adems contenga
los atributos "Secure" y "HttpOnly"
3.16 Verificar que la aplicacin limita el nmero de sesiones

3.0
concurrentes activas.
3.17 Verificar que una lista de sesiones activas est disponible

en el perfil de cuenta o similar para cada usuario. El
3.0
usuario debe ser capaz de terminar cualquier sesin
activa.
3.18 Verificar que al usuario se le sugiera la opcin de

terminar todas las otras sesiones activas despus de un 3.0
proceso de cambio de contrasea exitoso.
Referencias
Gua de pruebas OWASP 4.0: sesin de prueba de manejo

https://www.OWASP.org/index.php/Testing_for_Session_Management
Cheat Sheet Gestin de sesiones
https://www.OWASP.org/index.php/Session_Management_Cheat_Sheet

V4: Requisitos de verificacin del Control de acceso
Objetivo de control
Autorizacin es el concepto de permitir acceso a los recursos nicamente a aquellos que les
ha sido permitido utilizarlos. Se debe asegurar que la aplicacin verificada satisface los
siguientes requisitos de alto nivel:
Personas que acceden a recursos poseen credenciales vlidas para hacerlo.

Los usuarios se encuentran asociados con un conjunto bien definido de roles y
privilegios.
Los metadatos de Roles y permisos se encuentran protegidos de ataques de
reutilizacin o manipulacin.
Requisitos
Verificar que existe el principio de privilegio mnimo - los

usuarios slo deben ser capaces de acceder a las funciones,
archivos de datos, URL, controladores, servicios y otros
4.1 1.0
recursos, para los cuales poseen una autorizacin
especfica. Esto implica proteccin contra suplantacin de
identidad y elevacin de privilegios.
Verificar que el acceso a registros sensibles est protegido,

tal que slo objetos autorizados o datos sean accesibles por
4.4 cada usuario (por ejemplo, proteger contra la posible 1.0
manipulacin hecha por usuarios sobre un parmetro para
ver o modificar la cuenta de otro usuario).
Verificar que la navegacin del directorio est deshabilitada

a menos que esto sea deliberadamente deseado. Adems,
las aplicaciones no deben permitir el descubrimiento o
4.5 1.0
divulgacin de metadatos de archivos o directorios, como
carpetas que contengan Thumbs.db, DS_Store, o
directorios .git o SVN.
Verificar que los controles de acceso fallen de forma

4.8 1.0
segura.
Verificar que las mismas reglas de control de acceso

4.9 implcitas en la capa de presentacin son aplicadas en el 1.0
servidor.

Verificar que todos los atributos de usuario, datos e

informacin de las polticas utilizadas por los controles de
4.10 acceso no puedan ser manipulados por usuarios finales a 1.0
menos que sean especficamente autorizados.
Verificar que existe un mecanismo centralizado (incluyendo

las bibliotecas que requieren servicios de autorizacin
1.0
externa) para proteger el acceso a cada tipo de recursos
4.11
protegidos.
Verificar que todas las acciones de control de acceso

pueden ser registradas y que todas las acciones fallidas son 2.0
4.12
registradas.
Verificar que la aplicacin o su infraestructura emite tokens

anti-CSFR aleatorios existe otro mecanismo de proteccin 2.0
4.13
de la transaccin.
Verificar que el sistema se pueda proteger contra el acceso

permanente a funciones aseguradas, recursos o datos. Por
ejemplo, que el sistema utilice un recurso gobernante que 2.0
4.14
limite el nmero de ediciones por hora o para prevenir que
la base de datos sea sobre-utilizada por un nico usuario.
Verificar que la aplicacin disponga de autorizacin

adicional (como autenticacin aumentada o adaptacin de
autenticacin) para sistemas de valores bajos, y/o
3.0
segregacin de funciones para aplicaciones de alto valor
4.15
para cumplir con los controles anti fraude segn el anlisis
de riesgo de la aplicacin y fraudes cometidos en el pasado.
Verificar que la aplicacin aplique correctamente la

autorizacin contextual para no permitir la manipulacin 3.0
4.16
de parmetros de la URL.
Referencias
Gua de pruebas OWASP 4.0: Autorizacin

https://www.OWASP.org/index.php/Testing_for_Authorization
Cheat Sheet Control de acceso
https://www.OWASP.org/index.php/Access_Control_Cheat_Sheet

V5: Requisitos de verificacin para Manejo de entrada de datos
maliciosos
Objetivo de control
La debilidad ms comn de seguridad de las aplicaciones web es la falla en validar

apropiadamente el ingreso de datos que provienen del cliente o del ambiente antes de ser
utilizada. Esta debilidad conduce a casi todas las vulnerabilidades encontradas en
aplicaciones web, tales como cross site scripting (XSS), inyecciones SQL, inyeccin de
intrprete, ataques locale/Unicode, ataques a sistemas de archivos y desbordamientos de
bfers.
. Se debe asegurar que la aplicacin verificada satisface los siguientes requisitos de alto
nivel:
Todas las entradas son correctamente validadas y adecuadas para el propsito

previsto.
No debe confiarse en datos de una entidad externa o del cliente y deben ser
tratados como tales.
Requisitos
Desd
# Descripcin 1 2 3
e
Verificar que el entorno de ejecucin no es susceptible a

5.1 desbordamientos de bfer, o que los controles de seguridad 1.0
previenen desbordamientos de bfer.
Verificar que las fallas de validacin de entradas de datos del

5.3 1.0
lado del servidor sean rechazadas y registradas.
Verificar que se aplican las rutinas de validacin de entradas de

5.5 1.0
datos del lado del servidor.
Verificar que un nico control de validacin de entrada es

5.6 utilizado por la aplicacin para cada tipo de datos que es 1.0
aceptado.
Verificar que todas las consultas de SQL, HQL, OSQL, NOSQL y

procedimientos almacenados, llamadas de procedimientos
5.10 almacenados estn protegidos por la utilizacin de 2.0
declaraciones preparadas o parametrizacin de consultas, y por
lo tanto no sean susceptibles a la inyeccin de SQL

Desd
# Descripcin 1 2 3
e
Verificar que la aplicacin no es susceptible a la inyeccin LDAP,

5.11 2.0
o que los controles de seguridad previenen inyeccin LDAP.
Verificar que la aplicacin no es susceptible a la inyeccin de

comandos del sistema operativo, o que los controles de
5.12 2.0
seguridad previenen la inyeccin de comandos del sistema
operativo.
Verificar que la aplicacin no es susceptible a la inclusin de

5.13 archivo remoto (RFI) o inclusin de archivo Local (LFI) cuando el 3.0
contenido es utilizado como una ruta a un archivo.
Verificar que la aplicacin no es susceptible a ataques comunes

5.14 de XML, como manipulacin de consultas XPath, ataques de 2.0
entidad externa XML, y ataques de inyeccin XML.
Asegurar que todas las variables string utilizadas dentro de

HTML u otro lenguaje web interpretado en cliente se encuentra
apropiadamente codificada manualmente o se utiliza plantillas
5.15 2.0
que automticamente codifican contextualmente para asegurar
que la aplicacin no sea susceptible a ataques DOM Cross-Site
Scripting (XSS).
Si el framework de la aplicacin permite asignacin automtica

de parmetros en masa (tambin llamada enlace automtico de
variables o variable biding) desde la peticin entrante a un
5.16 2.0
modelo, verificar que campos sensibles de seguridad como
"accountBalance", "role" o "password" sean protegidos de
enlaces automticos maliciosos.
Verificar que la aplicacin contenga defensas contra los ataques

de contaminacin de parmetros HTTP (agregar parmetros a la
5.17 URL), particularmente si el framework de la aplicacin no hace 2.0
distincin sobre el origen de los parmetros de la peticin (GET,
POST, cookies, cabeceras, ambiente, etc.)
Verificar que las validaciones del lado del cliente se utilizan

5.18 como una segunda lnea de defensa, en adicin a la validacin 3.0
del lado del servidor.
Verificar que todos los datos de entrada sean validados, no

solamente los campos de formularios HTML sino tambin todos
los orgenes de entrada como las llamadas REST, parmetros de
consulta, encabezados HTTP, cookies, archivos por lotes,
5.19 3.0
fuentes RSS, etc.; mediante validacin positiva (lista blanca), o
utilizando otras formas de validacin menos eficaces tales como
listas de rechazo transitorio (eliminando smbolos defectuosos),
o rechazando malas entradas (listas negras).

Desd
# Descripcin 1 2 3
e
Verificar que datos estructurados fuertemente tipados son

validados un esquema definido incluyendo; caracteres
permitidos, longitud y patrones (p. ej. tarjeta de crdito o
5.20 3.0
telfono o validando que dos campos relacionados son
razonables, tales como validacin de coincidencia entre
localidad y cdigo postal).
Verificar que los datos no estructurados sean sanitizados

cumpliendo medidas genricas de seguridad tales como
caracteres permitidos, longitud y que caracteres
5.21 potencialmente dainos en cierto contexto sean anulados (p. ej. 3.0
nombres naturales con Unicode o apstrofos, como o
O'Hara)
Verificar que HTML no confiable proveniente de editores

WYSIWYG o similares sean debidamente sanitizados con un
5.22 3.0
sanitizador de HTML y se manejen apropiadamente segn la
validacin de entrada y codificacin.
Para tecnologas de plantilla de codificacin automtica, si sta

5.23 se ha deshabilitado, asegurar que la sanitizacin de HTML est 3.0
habilitada en su lugar.
Verificar que los datos transferidos desde un contexto DOM a

5.24 otro, utilice mtodos de JavaScript seguro, como pueden ser 3.0
.innerText y .val
Verificar que cuando se interprete JSON en navegadores, que

5.25 3.0
JSON.parse sea el utilizado para interpretarlo y no eval().
Verificar que los datos de autenticacin se eliminen del

5.26 almacenamiento del cliente, tales como el DOM del navegador, 3.0
despus de terminada la sesin.
Referencias
Gua de pruebas OWASP 4.0: Validacin de entradas de datos

https://www.OWASP.org/index.php/Testing_for_Input_Validation
Cheat Sheet: Validacin de entradas de datos
https://www.OWASP.org/index.php/Input_Validation_Cheat_Sheet

Gua de pruebas OWASP 4.0: pruebas de contaminacin de parmetro HTTP
https://www.OWASP.org/index.php/Testing_for_HTTP_Parameter_pollution_%28O
TG-INPVAL-004%29
Cheat Sheet: Inyeccin LDAP
https://www.OWASP.org/index.php/LDAP_Injection_Prevention_Cheat_Sheet
Gua de pruebas OWASP 4.0: Pruebas en el Cliente
https://www.OWASP.org/index.php/Client_Side_Testing
Cheat Sheet: Prevencin de Cross Site Scripting
https://www.OWASP.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_
Cheat_Sheet
OWASP: Proyecto codificacin de Java
https://www.OWASP.org/index.php/OWASP_Java_Encoder_Project
Para obtener ms informacin sobre codificacin automtica, consulte:
Reduccin de XSS a travs escape Context-Aware automtico en sistemas de plantilla

http://googleonlinesecurity.blogspot.com/2009/03/Reducing-XSS-by-Way-of-
Automatic.html
AngularJS Escape Contextual Estricto
https://docs.angularjs.org/Api/ng/Service/ $sce

V6: Codificacin / escape de salidas de datos
Esta seccin se incorpor en V5 en el Estndar de Verificacin de Seguridad en
Aplicaciones 2.0. Requisitos de ASVS 5.16 tratan la codificacin contextual de salida para
ayudar a prevenir Cross Site Scripting.

V7: Requisitos de verificacin para la criptografa en el
almacenamiento
Objetivo de control
Asegure que una aplicacin verificada satisfaga los siguientes requisitos de alto nivel:
Que todos los mdulos criptogrficos fallen de forma segura y que los errores sean
gestionados correctamente.
Que se utilice un generador de nmeros aleatorios adecuado cuando se requiere la
aleatoriedad.
Que el acceso a claves se gestiona de forma segura.
Requisitos
Verificar que todos los mdulos criptogrficos fallen

de forma segura, y que los errores sean manejados
7.2 1.0
de tal manera que no permitan ataques Oracle
padding.
Verificar que todos los nmeros aleatorios,

nombres aleatorios de archivo, GUIDs aleatorios y
cadenas aleatorias sean generados usando un
7.6 mdulo criptogrfico aprobado del generador de 1.0
nmeros aleatorios cuando se pretende que estos
valores no puedan ser adivinados o predecibles
para un atacante.
Verificar que los algoritmos criptogrficos utilizados

7.7 por la aplicacin hayan sido validados contra FIPS 1.0
140-2 o un estndar equivalente.
Verificar que los mdulos criptogrficos operen en

7.8 su modo aprobado segn sus polticas de seguridad 1.0
publicadas.
Verificar que existe una poltica explcita para el

manejo de las claves criptogrficas (por ejemplo,
7.9 generadas, distribuidas, revocadas y vencidas). 1.0
Verificar que el ciclo de vida de las clave se aplique
correctamente.

Verificar que los consumidores de servicios

criptogrficos no poseen acceso directo a los datos
7.11 de la clave. Aislar procesos criptogrficos, 3.0.1
incluyendo secretos maestros y considerar el uso de
un mdulo de seguridad de hardware (HSM).
La informacin de identificacin personal debe

almacenarse de forma cifrada y verificar que la
7.12 3.0
comunicacin se lleve a cabo utilizando de canales
protegidos.
Verificar que contraseas y claves criptogrficas

sean sobreescritas con ceros en memoria tan
7.13 3.0.1
pronto no sean necesarias, con el fin de mitigar
ataques de volcado de memoria.
Verificar que todas las claves y contraseas sean

7.14 reemplazables, y sean generadas o reemplazadas 3.0
durante la instalacin.
Verificar que los nmeros aleatorios sean creados

con adecuada entropa, incluso cuando la aplicacin
7.15 3.0
se encuentre bajo carga intensa, o que la aplicacin
se degrade armoniosamente en tales circunstancias.
Referencias
Gua de pruebas OWASP 4.0: Pruebas para criptografa dbil

https://www.owasp.org/index.php/Testing_for_weak_Cryptography
Cheat Sheet: Almacenamiento criptogrfico
https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

V8: Requisitos de verificacin de gestin y registro de errores
Objetivo de control
El objetivo principal de la gestin y registro de errores es proporcionar una reaccin til

para los usuarios, administradores y equipos de respuesta a incidentes. El objetivo no es
crear cantidades masivas de registros, sino crear registros de alta calidad, con informacin
til y desechando ruido.
Los registros de bitcora de alta calidad a menudo contienen datos confidenciales y tambin
deben ser protegidos segn las leyes de privacidad de datos o directivas. Esto debe incluir:
No recoger o registrar informacin confidencial si no es necesaria.

Garantizar que toda la informacin registrada se gestiona de forma segura y es
protegida segn su clasificacin de datos.
Asegurar que los registros de bitcora no sean almacenados indeterminadamente,
sino que posean un ciclo de vida til lo ms corta posible.
Si los registros contienen datos privados o confidenciales, cuya definicin vara de pas a
pas, stos se convierten en parte de la informacin sensible y por lo tanto resulta muy
atractiva para los atacantes.
Requisitos
8.1 Verificar que la aplicacin no emita mensajes de

error o rastros de pilas que contengan datos
sensibles que podran ayudar a un atacante, 1.0
incluyendo el identificador de sesin, versiones de
software/entorno y datos personales.
8.2 Verificar que la lgica de manejo de errores en

controles de seguridad niegue el acceso por 1.0
defecto.
8.3 Verificar que los controles del registro de seguridad

proporcionen la capacidad para registrar los
eventos de xito y sobre todo los eventos de falla 1.0
que son identificados como relevantes para la
seguridad.
8.4 Verificar que cada registro de evento incluya la

informacin necesaria para permitir una eventual 1.0
investigacin y correlacin con otros eventos.

8.5 Verificar que todos los eventos que incluyen datos
no confiables no se ejecuten como cdigo en el 1.0
software destinado a la visualizacin del registro.
8.6 Verificar que los registros de seguridad estn

protegidos contra modificacin y acceso no 1.0
autorizado.
8.7 Verificar que la aplicacin no registre datos

sensibles definidos en las leyes o regulaciones de
privacidad local, datos organizacionales sensibles
definidos por una evaluacin de riesgos, o datos de 3.0
autenticacin sensible que podran ayudar a un
atacante, incluyendo identificadores de sesin del
usuario, contraseas, hashes o tokens de APIs.
8.8 Verificar que todos los smbolos no imprimibles y

separadores de campos estn codificados
correctamente en las entradas del registro, para 2.0
evitar la inyeccin del registro que no permita
seguir las pistas de un acto malicioso.
8.9 Verificar que los campos del registro de fuentes

confiables y no confiables sean identificables en las 2.0
entradas del registro.
8.10 Verificar que un registro de auditora o similar

3.0
permita la no repudiacin de transacciones claves.
8.11 Verificar que los registros de seguridad poseen

alguna forma de verificacin o control de integridad 3.0
para prevenir modificaciones no autorizadas.
8.12 Verificar que los registros estn almacenados en

una particin diferente a donde ejectua la 3.0
aplicacin con una rotacin de registros adecuada.
Referencias
OWASP Testing Guide 4.0: Pruebas de gestin de Errores

https://www.owasp.org/index.php/Testing_for_Error_Handling

V9: Requisitos de Verificacin de Proteccin de Datos
Objetivo de control
Hay tres elementos clave para la proteccin de datos: Confidencialidad, Integridad y

Disponibilidad (CIA por sus siglas en ingls). Este estndar asume que la proteccin de datos
se aplica en un sistema de confianza, como un servidor, que ha sido protegido debidamente
y dispone de protecciones suficientes.
Las aplicaciones web deben asumir que todos los dispositivos de un usuario puedan ser
comprometidos de alguna manera. Cuando una aplicacin transmite o almacena
informacin sensible dentro de dispositivos inseguros, como equipos compartidos,
telfonos y tabletas, la aplicacin es responsable de que los datos almacenados en estos
dispositivos sean cifrados y no pueden ser fcilmente o ilcitamente obtenidos, alterados o
divulgados.
Se debe asegurar que la aplicacin verificada satisface los siguientes requisitos de

proteccin de datos de alto nivel:
Confidencialidad: los datos deben ser protegidos de observacin no autorizada o la

divulgacin tanto en trnsito como cuando estn almacenados.
Integridad: los datos deben protegerse siendo creados maliciosamente, alterados o
eliminados por los intrusos no autorizados.
Disponibilidad: los datos deben estar disponibles para usuarios autorizados cuando
sea necesario
Requisitos
Verificar que todos los formularios que contengan

informacin sensible se les haya desactivado el
9.1 1.0
almacenamiento de cach en el cliente, incluyendo
funciones de autocompletar.
Verificar que la lista de datos sensibles procesados por la

aplicacin se encuentra identificada, y que existe una
9.2 poltica explcita de cmo debe controlarse el acceso a 1.0
estos datos, cifrarse y reforzarse bajo las directivas de
proteccin de datos pertinentes.

Verificar que toda informacin sensible es envada al

servidor en el cuerpo o cabeceras del mensaje HTTP (por
9.3 1.0
ejemplo, los parmetros de la URL nunca se deben utilizar
para enviar datos sensibles).
Verificar que la aplicacin establece encabezados anti-
cach adecuados segn el riesgo de la aplicacin, tales
como las siguientes:
Expires: Tue, 03 Jul 2001 06:00:00 GMTT
Last-Modified: {now} GMT
9.4 Cache-Control: no-store, no-cache, must- 1.0
revalidate, max-age=0
Cache-Control: post-check = 0, pre-check =
0
Pragma: no-cache
Verificar que, en el servidor, todas las copias almacenadas

en cach o temporales de datos sensibles estn protegidos
9.5 1.0
de accesos no autorizados o son purgados/invalidados
despus del acceso por parte del usuario autorizado.
Verificar que existe un mecanismo para eliminar de la

9.6 aplicacin todo tipo de dato sensible luego de transcurrido 1.0
el tiempo definido por la poltica de retencin.
Verificar que la aplicacin reduce al mnimo el nmero de

9.7 parmetros en una solicitud, como campos ocultos, 2.0
variables de Ajax, cookies y valores en encabezados.
Verificar que la aplicacin tenga la capacidad para detectar

y alertar sobre un nmero anormal de solicitudes para la
9.8 2.0
recoleccin de datos por medio de extraccin de pantalla
(screen scrapping).
Verificar que datos almacenados en el cliente (como

almacenamiento local de HTML5, almacenamiento de la
9.9 sesin, IndexedDB, cookies normales o las cookies de 3.0.1
Flash) no contengan informacin sensible o informacin
personal identificable.
Verificar que el acceso a datos sensibles es registrado en

bitcora, los datos son registrados acorde a las directivas
9.10 3.0
de proteccin de datos o cuando el registro de los accesos
es requerido.
Verificar que la informacin sensible mantenida en

9.11 memoria es sobre escrita con ceros tan pronto como no es 3.0.1
requerida, para mitigar ataques de volcado de memoria.

Referencias
Cheat Sheet - Proteccin de la privacidad del usuario

https://www.owasp.org/index.php/User_Privacy_Protection_Cheat_Sheet

V10: Requisitos de Verificacin de Seguridad de las Comunicaciones
Objetivo de control
Se debe asegurar que la aplicacin verificada satisfaga los siguientes requisitos de alto nivel:
Que se utilice TLS donde se transmite informacin sensible

Que se utilicen algoritmos y cifradores fuertes en todo momento.
Requisitos
10.1 Verificar que puede construirse la cadena de confianza desde

una CA (Autoridad de Certificacin) para cada certificado TLS 1.0
(Transport Layer Security) del servidor, y que cada certificado
del servidor sea vlido.
10.3 Verificar que se utiliza TLS para todas las conexiones

(incluyendo conexiones back-end y externas) autenticadas o
que involucran funciones o informacin sensible, y no 3.0
recaigan en protocolos inseguros o sin cifrado. Asegrese de
que la alternativa ms fuerte es el algoritmo preferido.
10.4 Verificar que se registran los fallos de conexiones TLS en el

1.0
backend.
10.5 Verificar que se construyen las cadenas de confianza para

todos los certificados de clientes mediante anclajes de 1.0
confianza e informacin de revocacin de certificados.
10.6 Verificar que todas las conexiones a sistemas externos que

involucran acciones o informacin sensible sean 1.0
autenticadas.
10.8 Verificar que haya una sola implementacin estndar de TLS

utilizada por la aplicacin la cual est configurada para 1.0
operar en un modo aprobado de operacin.
10.10 Verificar que el certificado de clave pblica se encuentre 3.0.1

fijado (Certificate Pinning) con la clave de produccin y la

clave pblica de respaldo. Para obtener ms informacin,
vea las referencias abajo.
10.11 Verificar que los encabezados HTTP Strict Transport Security 3.0
sean incluidos en todas las peticiones y para todos los

subdominios, como Strict-Transport-Security: max-age =
15724800; includeSubdomains

10.12 Verificar que la URL del sitio web de produccin haya sido 3.0
enviada a una lista precargada de dominios de Strict
Transport Security(STS) mantenidos por proveedores de
navegadores web. Para obtener ms informacin, vea las
referencias abajo.
10.13 Asegurar que foward secrecy se est utilizando para mitigar 3.0

que atacantes pasivos puedan grabar el trfico.
V10.14 Verificar que una adecuada revocacin de certificados, tal 3.0

como el protocolo de estatus de certificado en lnea (OSCP),
est habilitado y configurado para determinar el estado de
vigencia del certificado.
V10.15 Verificar que se utilicen nicamente algoritmos, cifradores y

protocolos fuertes, a travs de toda la cadena de confianza, 3.0
incluyendo certificados raz y certificados intermediarios de
la autoridad certificadora seleccionada.
V10.16 Verificar que la configuracin de TLS est en lnea con las

mejores prcticas actuales, particularmente debido a que 3.0
configuraciones comunes se convierten en inseguras a
medida que transcurre el tiempo.
Referencias
Cheat Sheet: TLS

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
Notas sobre "Modos aprobados de TLS": En el pasado, el ASVS hizo referencia al
estndar estadounidense FIPS 140-2, pero como es un estndar global, la aplicacin
de estndares americanos puede resultar difcil, contradictorio o confuso de aplicar.
Un mejor mtodo de cumplimiento para el punto 10.8 es revisar guas tales como
(https://wiki.mozilla.org/Security/Server_Side_TLS ), generar configuraciones bien
conocidas (https://mozilla.github.io/server-side-tls/ssl-config-generator/) y utilizar
herramientas de evaluacin de TLS conocidas, como sslyze, diversos escneres de
vulnerabilidades o servicios confiables de evaluacin en lnea de TLS para obtener un
nivel de seguridad deseado. En general, vemos el incumplimiento de esta seccin

debido al uso de cifradores anticuados, algoritmos inseguros, la falta de perfect
secret fowarcy, protocolos de SSL obsoletos o inseguros, algoritmos de Cifrado
dbiles y as sucesivamente.
Fijacin de Certificado: Por mas informacin consulte
https://tools.ietf.org/html/rfc7469 . La razn de ser tras el fijado de certificados para
produccin y copia de claves es la continuidad del negocio - vea
https://noncombatant.org/2015/05/01/about-http-public-key-pinning/
Pre-Cargamiento de HTTP Transporte de Seguridad Estricto:
https://www.Chromium.org/hsts

V11: Requisitos de verificacin de configuracin de seguridad HTTP
Objetivo de control
Asegure que la aplicacin verificada satisfaga los siguientes requisitos de alto nivel:
El servidor de aplicaciones est convenientemente endurecido de una configuracin

preestablecida
Toda respuesta HTTP contiene su tipo de contenido establecido utilizando un
conjunto de caracteres seguro.
Requisitos
Verificar que la aplicacin acepte solo un conjunto

definido de mtodos de solicitud HTTP y que son
11.1 necesarios, como GET y POST, y mtodos no 1.0
utilizados (por ejemplo: TRACE, PUT y DELETE) se
encuentran explcitamente bloqueados.
Verificar que cada respuesta HTTP contenga una

cabecera content-type en la que se especifique un
11.2 1.0
conjunto utilizando un conjunto de caracteres
seguros (Ejemplo: UTF-8, ISO 8859-1).
Verificar que los encabezados HTTP agregados por

un proxy confiable o dispositivos SSO, tales como un
11.3 2.0
token de portador (bearer), son autenticados por la
aplicacin.
Verificar que el cabezal X-FRAME-OPTIONS se

11.4 encuentra especificado para los sitios que no deben 3.0.1
ser embebidos en X-Frame en sitios de terceros
Verificar que los encabezados HTTP o cualquier

parte de la respuesta HTTP no expongan
11.5 2.0
informacin detallada de la versin de los
componentes del sistema.
Verificar que todas las respuestas del API contienen

opciones X-Content-Type: nosniff y Content-
11.6 Disposition: attachment; filename="api.json" (u 3.0
otro nombre de archivo apropiado para el tipo de
contenido).

Verificar que la poltica de seguridad de contenido
(CSPv2) est en uso de tal manera que ayude a
11.7 3.0.1
mitigar vulnerabilidades de inyeccin comunes de
DOM, XSS, JSON y Javascript
Verificar que el encabezado "X-XSS-Protection: 1;

11.8 mode=block" est presente para habilitar a los 3.0
navegadores a filtrar XSS reflejados
Referencias
Gua de pruebas OWASP 4.0: Testeo para la manipulacin de verbos HTTP

https://www.owasp.org/index.php/Testing_for_HTTP_Verb_Tampering_%28OTG-
INPVAL-003%29
Adicin de Content-Disposition a las respuestas API ayuda a prevenir muchos de los
ataques basados en errores o malinterpretaciones en el tipo MIME entre cliente y
servidor, y la opcin de "nombre de archivo" especficamente ayuda a prevenir
ataques de tipo Descarga de Archivos Reflejada.
https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-
Download-A-New-Web-Attack-Vector.pdf

V12: Requisitos de verificacin de configuracin de seguridad
Esta seccin se incorpor en V11 en la versin 2.0 del Estndar de Verificacin de
Seguridad en Aplicaciones.

V13: Requisitos de verificacin para Controles Malicioso
Objetivo de control
La actividad maliciosa se debe manejar con seguridad y adecuadamente para no

afectar el resto de la aplicacin.
No posee bombas de tiempo ni otros ataques basados en tiempo
No realiza "phone home" a destinos malintencionados o no autorizados
La aplicacin no posee puertas traseras, huevos de Pascua, ataques salami o fallos de
lgica que pueden ser controlados por un atacante
El cdigo malicioso es extremadamente raro difcil de detectar. La revisin manual lnea por
lnea del cdigo puede ayudar a encontrar bombas lgicas, pero incluso el ms
experimentado revisor de cdigo tendr que esforzarse para encontrar cdigo malicioso
aunque sepa que existe.
Requisitos
Verificar que toda actividad maliciosa sea

adecuadamente aislada o encajonada para retrasar
13.1 2.0
y disuadir a los atacantes de atacar a otras
aplicaciones.
Verificar que el cdigo fuente de la aplicacin y

tantas bibliotecas de terceros como sean posibles,
no poseen puertas traseras, huevos de pascua, o
13.2 3.0.1
fallas de lgica en la autenticacin, control de
acceso, validaciones de entrada y lgica de negocio
en transacciones de alto valor.
Referencias
http://www.dwheeler.com/essays/apple-goto-fail.html

V14: Requisitos de verificacin de seguridad interna
Esta seccin se incorpor en V13 en la versin 2.0 del Estndar de Verificacin de
Seguridad en Aplicaciones.

V15: Requisitos de verificacin para lgica de negocios
Objetivo de control
El flujo de la lgica de negocio es secuencial y en orden

La Lgica de negocios incluye lmites para detectar y evitar ataques automatizados,
como las continuas transferencias de fondos pequeos, agregando 1 milln amigos
uno a uno y as sucesivamente.
Flujos de lgica de negocios de alto valor han considerado casos de abuso y agentes
maliciosos y poseen protecciones contra la falsificacin, alteracin, repudio,
revelacin de informacin y ataques a la elevacin de privilegios.
Requisitos
V15.1 Verificar que la aplicacin slo procese flujos lgicos

de negocios en orden secuencial, con todos los
pasos procesados en tiempo humano realista, y no
2.0
procesados fuera de orden, con pasos salteados,
con pasos del proceso de otro usuario, o de
transacciones muy rpidamente enviadas.
V15.2 Verificar que la aplicacin tiene lmites de negocio y

los aplique correctamente por cada usuario, con
2.0
alertas configurables y reacciones automatizadas
ante ataques inusuales o automticos.
Referencias
Gua de pruebas OWASP 4.0: Pruebas de lgica de negocios

https://www.OWASP.org/index.php/Testing_for_business_logic
Cheat Sheet: Lgica de Negocio
https://www.OWASP.org/index.php/Business_Logic_Security_Cheat_Sheet

V16: Requisitos de verificacin de archivos y recursos
Objetivo de control
Datos no confiables deben ser gestionados como tales y de forma segura

Datos Obtenidos de fuentes no confiables sean almacenan fuera del webroot y
posean permisos limitados.
Requisitos
16.1 Verificar que las URL de redireccionen y reenven

slo a destinos clasificados en la lista blanca, o 2.0
mostrar una advertencia cuando se redirija a
contenido potencialmente no confiable.
16.2 Verificar que archivos no confiables enviados a la

aplicacin no sean utilizados directamente por
comandos de I/O (Entrada/Salida) de archivos,
especialmente para proteger contra manipulaciones 2.0
de rutas, archivo local incluido, manipulacin de
tipo mime y vulnerabilidades de inyeccin de
comandos de sistema operativo.
16.3 Verificar que los archivos procedentes de fuentes

no confiables sean validados para ser del tipo del
cual se espera y sean analizados por escneres 2.0
antivirus para evitar la carga de contenido malicioso
conocido.
16.4 Verificar que datos no confiables no se utilicen en

funcionalidades de reflexin, cargado de clases o 2.0
insercin para prevenir vulnerabilidades de
inclusin de archivos remotos/locales.
16.5 Verificar que datos no confiables no se utilicen en

recursos de dominios compartidos (CORS) para 2.0
proteger contra el contenido remoto arbitrario.
16.6 Verificar que los archivos obtenidos de fuentes no

confiables se almacenen fuera del webroot, con
3.0
permisos limitados, preferiblemente con una fuerte
validacin.

16.7 Verificar que el servidor web o de aplicacin se

encuentra configurado por defecto para negar el
2.0
acceso a recursos remotos o sistemas fuera del
servidor web o de aplicacin.
16.8 Verificar que el cdigo de la aplicacin no ejecuta

3.0
datos cargados obtenidos de fuentes no confiables.
16.9 Verificar que no utiliza Flash, Active-X, Silverlight,

NACL, Java del lado del cliente u otras tecnologas
del lado del cliente que no sean soportadas de 2.0
forma nativa a travs de los estndares de
navegador W3C.
Referencias
Manejo de Extensin de Archivo para informacin confidencial:

https://www.owasp.org/index.php/Unrestricted_File_Upload

V17: Requisitos de verificacin Mvil
Objetivo de control
Esta seccin contiene controles especficos para aplicaciones mviles. Estos controles han
sido de-duplicados de la versin 2.0, por lo que deben tomarse en conjunto con el resto de
las secciones de los niveles correspondientes de Verificacin ASVS.
Las aplicaciones mviles deben:
Deben tener el mismo nivel de controles de seguridad tanto en el cliente mvil como
en el servidor, mediante la aplicacin de controles de seguridad en un entorno de
confianza.
Activos de Informacin sensible almacenados en el dispositivo debe realizarse de un
modo seguro.
Todos los datos sensibles transmitidos desde el dispositivo deben ser hechos
teniendo en mente la seguridad en la capa de transporte.
Requisitos
17.1 Verificar que los valores de identificadores

almacenados en el dispositivo y recuperables por 2.0
otras aplicaciones, como el nmero de UDID o IMEI
no se utilicen como tokens de autenticacin.
17.2 Verificar que la aplicacin mvil no almacene datos

sensibles en recursos compartidos potencialmente
2.0
no cifrados en el dispositivo (tarjeta SD o carpetas
compartidas).
17.3 Verificar que los datos sensibles no se almacenen

sin proteccin en el dispositivo, incluso en reas 2.0
protegidas del sistema como llaveros.
17.4 Verificar que las contraseas, claves secretas y

tokens de APIs se generan dinmicamente en la 2.0
aplicacin mvil.

17.5 Verificar que la aplicacin mvil evite fugas de

informacin sensible (por ejemplo, capturas de
pantalla de la aplicacin actual sean guardadas 2.0
mientras la aplicacin est en segundo plano o
escribiendo informacin sensible en consola).
17.6 Verificar que la aplicacin solicita permisos mnimos

2.0
para la funcionalidad y recursos requeridos.
17.7 Verificar que el cdigo sensible de la aplicacin sea 2.0

cargado de forma no predecible en memoria (
utilizando ASLR por ejemplo).
17.8 Verificar que se encuentren presentes tcnicas anti 2.0

depuracin suficientes para impedir o retrasar a
posibles atacantes de inyectar depuradores en la
aplicacin mvil (GDB, por ejemplo).
17.9 Verificar que la aplicacin no exporte actividades 2.0

intents, o proveedores de contenido con
informacin sensible a otras aplicaciones mviles
posibles de ser explotados por otras aplicaciones en
el mismo dispositivo.
17.10 Verificar que la informacin sensible almacenada en 3.0.1

memoria es sobreescrita con ceros tan pronto como
no deje de ser requerida, con el fin de mitigar
ataques de volcado de memoria.
17.11 Verificar que las actividades expuestas, intents, 3.0.1

proveedores de contenido realicen validaciones de
los datos de entrada.
Referencias
Proyecto OWASP de Seguridad Mvil:

https://www.OWASP.org/index.php/OWASP_Mobile_Security_Project
iOS Developer Cheat Sheet:
https://www.OWASP.org/index.php/IOS_Developer_Cheat_Sheet

V18: Requisitos de verificacin de servicios Web
Objetivo de control
Asegrese de que la aplicacin verificada, de utilizar servicios web REST o SOAP posean:
Autenticacin adecuada, gestin de sesin y autorizacin de todos los servicios web

Validacin de entrada de datos de todos los parmetros que transiten de zonas de
menor a mayor confianza
Interoperabilidad bsica de la capa de servicios web SOAP para promover el uso de
la API.
Requisitos
18.1 Verificar que el mismo estilo de codificacin se 3.0

utiliza tanto en el cliente como el servidor.
18.2 Verificar que el acceso a las funciones de 3.0

administracin y gestin de la aplicacin
proveedora de servicios web sea limitado a los
administradores.
18.3 Verificar que existen esquemas XML o JSON y que 3.0

stos son verificados por la aplicacin antes de
aceptar datos de entrada.
18.4 Verificar que todos los datos de entrada se 3.0

encuentren limitados a un tamao adecuado.
18.5 Verificar que los servicios web basados en SOAP son 3.0.1
compatibles con el perfil bsico de
interoperabilidad de servicios Web (WS-I) como
mnimo. Esencialmente, eso implica compatibilidad
con cifrado TLS.
18.6 Verificar el uso de autenticacin y autorizacin 3.0

basada en sesiones. Por favor refirase a las
secciones 2, 3 y 4 para mayor orientacin. Evite el
uso de "claves de API" estticas y enfoques
similares.

18.7 Verificar que los servicios REST se encuentren 3.0.1

protegidos de Falsificacin de Peticiones en Sitos
Cruzados (CSRF), mediante el uso de al menos uno o
mas de los siguientes mecanismos: Verificaciones
de ORIGIN, CSRF nonces, verificaciones de referrer o
el envo doble de valores en cookie y en el servicio
(double submit cookie pattern)
18.8 Verificar que los servicios REST comprueben 3.0

explcitamente que el Content-Type entrante sea el
que se espera, como aplicacin/xml o
aplicacin/json.
18.9 Verificar que el contenido de los mensajes se 3.0.1

encuentra firmado para asegurar el transporte
confiable entre el cliente y el servicio, utilizando
JSON Web Signing o WS-Security para servicios
SOAP.
18.10 Verificar que no existen rutas de acceso alternativas 3.0

y menos seguras.
Referencias
Gua de pruebas de OWASP 4.0: Configuracin y Despliegue

https://www.owasp.org/index.php/Testing_for_configuration_management
Cheat Sheet: Falsificacin de Peticiones en Sitos Cruzados
https://www.owasp.org/index.php/Cross-
Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
JSON Web Tokens (y su firma)

https://jwt.io/

V 19. Requisitos de Configuracin
Objetivo de control
Asegrese de que la aplicacin verificada:
Utilice bibliotecas y una plataforma actualizada.

Una configuracin segura por omisin.
Un Hardening suficiente de tal forma que los cambios realizados por un usuario no
resulten en exposiciones innecesarias o creen debilidades de seguridad o fallas a los
sistemas subyacentes.
Requisitos
Todos los componentes deben estar actualizados a

las configuraciones y versiones de seguridad
adecuadas. Esto debera incluir la eliminacin de
19.1 configuraciones y carpetas innecesarias como 3.0
aplicaciones de ejemplo, documentacin de
plataforma y usuarios pre-establecidos o de
ejemplo.
Las comunicaciones entre componentes, tales como

entre el servidor de aplicaciones y el servidor de
19.2 base de datos, deberan ser cifradas, 3.0
particularmente cuando los componentes estn en
diferentes contenedores o en sistemas diferentes.
Las comunicaciones entre componentes, tales como

entre el servidor de aplicaciones y el servidor de
19.3 3.0
base de datos deberan autenticarse utilizando una
cuenta con los mnimos privilegios necesarios.
Verificar que los despliegues de la aplicacin se

encuentren dentro de Sandboxes, en contenedores
19.4 3.0
o aislados para retrasar y disuadir a los atacantes de
atacar a otras aplicaciones.
Verificar que los procesos de compilacin y

19.5 despliegue de la aplicacin se realizan de forma 3.0
segura.

Verificar que los administradores autorizados

posean la capacidad de verificar la integridad de
19.6 3.0
todas las configuraciones de seguridad pertinentes
para garantizar que no hayan sido manipuladas.
Verificar que todos los componentes de aplicacin

19.7 3.0
se encuentren firmados.
Verificar que los componentes de terceros

19.8 3.0
proceden de repositorios de confianza.
Verificar que los procesos de compilacin para los

lenguajes de nivel de sistema operativo tengan
19.9 3.0
todas las banderas de seguridad activas, tales como
controles de seguridad, DEP y ASLR.
Verificar que todos los recursos de la aplicacin se

encuentran alojados en la aplicacin en vez de
19.10 3.0.1
confiar en un CDN o proveedores externos, tales
como bibliotecas JavaScript, estilos CSS o web fonts
Referencias
Gua de pruebas de OWASP 4.0: Configuracin y Despliegue

https://www.owasp.org/index.php/Testing_for_configuration_management

Apndice A: Qu sucedi con
# Descripcin Estado Elimina Razn

Original do
2.3 Verificar que, si se supera un nmero Obsoleto 2.0 Substituido por un

mximo de intentos de autenticacin, la requerimiento ms complejo
cuenta ser bloqueada por un perodo de (v2.20)
tiempo suficiente para disuadir ataques de
fuerza bruta.
2.5 Verificar que todos los controles de Combinado 3.0 Generalizado para incluir
autenticacin (incluyendo las bibliotecas que todos los controles de
requieren servicios de autenticacin seguridad y se traslad a 1.10
externos) tengan una implementacin
centralizada.
2.10 Verificar que autenticacin sea requerida Obsoleto 2.0 Se quita el control debido a
antes de que se permitan cualquier que la re- autenticacin se
operacin sensible especficas de la observa raramente.
aplicacin.
2.11 Verificar que despus de un perodo de Obsoleto 2.0 Expiracin absoluta de

tiempo configurable por un administrador, tiempos de espera y
las credenciales de autenticacin expiren. expiracin credencial ha sido
eliminado por no ser un
control eficaz.
2.14 Verificar que todas las credenciales de Actualizado 2.0 Se convirti en V2.21
autenticacin para acceder a servicios
externos a la aplicacin se encuentren
cifradas y almacenadas en un lugar protegido
(no en cdigo fuente).
2.15 Verificar que todo el cdigo de aplicacin o Se traslad 2.0 Se traslad a V13 - cdigo
uso de controles de autenticacin no es este malicioso
afectado por cualquier cdigo malicioso.
2.30 Verificar que si la aplicacin permite a los Obsoleto 3.0.1 Muy ambiguo para ser
usuarios autenticarse, se provee un probado, de hecho, es un
mecanismo de autenticacin seguro resumen de los
requerimientos de V2
3.8 Verificar que se modifique el identificador de Actualizado 3.0 Contemplado en 3.7

sesin cuando haya re-autenticacin

3.9 Compruebe que el identificador de sesin se Actualizado 3.0 Contemplado en 3.7
cambie o elimine al salir
3.13 Verificar que todo el cdigo de aplicacin o Se traslad 2.0 Se traslad a V13 - cdigo
uso de controles de gestin de sesin no se malicioso
encuentre afectado por cdigo malicioso
3.14 Verificar que los tokens de sesin Actualizado 3.0 Se traslad a 3.13
autenticados usando cookies estn
protegidos por el uso de "HttpOnly".
3.15 Verificar que los tokens de sesin Actualizado 3.0 Se traslad a 3.13
autenticados usando cookies estn
protegidos con el atributo "secure".
4.2 Verificar que los usuarios slo pueden Actualizado 3.0 Contemplado en 4.1
acceder a URLs seguras que poseen una
autorizacin especfica.
4.3 Verificar que los usuarios slo puedan Actualizado 3.0 Contemplado en 4.1
acceder a los archivos de datos asegurados
para los que poseen una autorizacin
especfica.
4.13 Compruebe que las limitaciones en entrada y Se traslad 3.0 Se traslad a la lgica de
acceso impuestas por reglas de negocios negocio de V15
sobre la aplicacin (como lmites de
transacciones diarias o secuenciacin de las
tareas) no sean sobrepasadas.
4.15 Verificar que todo el cdigo de aplicacin o Se traslad 2.0 Se traslad a controles
uso de controles de acceso no se vea maliciosos V13
afectado por cualquier cdigo malicioso.
5.2 Verificar que un patrn de validacin positivo Obsoleto 2.0 Removido debido a que es
es definido y aplicado a todas las entradas de demasiado difcil de aplicar
datos particularmente para
entradas de texto de forma
libre
5.4 Verificar que se haya especificado un Obsoleto 3.0 Removido debido a que es
conjunto de caracteres como UTF-8, para demasiado difcil de aplicar en
todas las fuentes de entrada la mayora de los lenguajes de
programacin
5.7 Verificar que todos los fallos de validacin Obsoleto 3.0 Removido, debido a que
de entrada se registren. creara muchos registros

intiles que seran ignorados
5.8 Verificar que toda entrada de datos es Obsoleto 3.0 Removido ya que el tipo 1 JSP
cannica para todos los decodificadores tecnologa especfica no es un
downstream o intrpretes antes de la problema para los marcos de
validacin. desarrollo ms modernos
5.9 Verificar que todos los controles de Se traslad 2.0 Se traslad a controles
validacin de entrada dedatos no sean maliciosos V13
afectados por cualquier cdigo malicioso
5.14 Verificar que el entorno de ejecucin no es Combinado 3.0 Se fusion con V5.13
susceptible a las inyecciones de XML o que
controles de seguridad impidan inyecciones
de XML
5.15 --REQUISITO VACO-- Eliminado 3.0 Este requisito nunca existi
5.19 Verificar que para cada tipo de Combinado 3.0 Generalizado para incluir
codificacin/escape de salida realizado por la todos los controles de
aplicacin, haya un control de seguridad seguridad y se traslad a 1.10
nico para ese tipo de salida para el destino
intencionado
7.1 Verificar que todas las funciones Obsoleto 3.0 Muchas de las aplicaciones
criptogrficas utilizadas para proteger modernas de respuesta
secretos del usuario de la aplicacin se rpida y mvil incluyen esto
ejecutan del lado del servidor por diseo
7.3 Verificar que el acceso a cualquier secreto(s) Se traslad 3.0 Se traslad a V2.29
maestro est protegido de accesos no
autorizados (un secreto maestro es una
credencial de aplicacin almacenada como
texto simple en el disco que se utiliza para
proteger el acceso a la informacin de
configuracin de seguridad).
7.4 Verificar que los hashes de contraseas son Se traslad 2.0 Se traslad a V2.13
salados cuando sean creados
7.5 Verificar que se registran en una bitcora las Obsoleto 2.0 Creacin de registros log
fallas de mdulo criptogrfico innecesarios que no son
revisados nunca es
contraproducente

7.10 Verificar que todo el cdigo de soporte o que Se traslad 2.0 Se traslad a V13
est utilizando un mdulo criptogrfico no
sea afectado por cualquier cdigo malicioso
8.2 Verificar que toda la gestin de errores se 3.0 Obsoleto

realice en dispositivos confiables
8.3 Verificar que todos los controles de registro Se traslad 3.0 Se convirti en un control
se ejecuten en el servidor. arquitectnico ms genrico
en V1.13
8.9 Verifique que haya una implementacin Se traslad 3.0 Se convirti en un control
nica de registro de bitcora a nivel de la arquitectnico ms genrico
aplicacin que sea utilizada por el software. en V1.13
8.11 Verificar que una herramienta de anlisis del Obsoleto 3.0 Removido ya que no requiere
registros de bitcora se encuentre disponible de software seguro
al analista el cual le permita buscar eventos
basados en combinaciones de criterios de
bsqueda en todos los campos en el formato
de registro log compatibles con este sistema.
8.12 Verificar que todo el cdigo de la aplicacin o Se traslad 2.0 Se traslad a controles
uso de controles de registro de bitcora y maliciosos V13
control de errores no sea afectado por
cualquier cdigo malicioso.
8.15 Verificar que el registro de bitcora se realice Obsoleto 3.0 Eliminado debido a que es
antes de ejecutar la transaccin. Si el registro control demasiado detallado
de bitcora no tuvo xito (p. ej. disco que slo sera aplicable a un
completo, permisos insuficientes) la pequeo porcentaje de todas
aplicacin falla de forma segura. Esto es, las applicaciones
para cuando la integridad y no repudio son
imprescindibles.
10.2 Verificar que conexiones TLS no caigan de Combinado 3.0 Se fusion con 10.3
nuevo a una conexin insegura HTTP
10.7 Verificar que todas las conexiones a sistemas

externos que involucran informacin
confidencial o usen una cuenta que se ha
establecido con privilegios mnimos
necesarios para que la aplicacin funcione
correctamente
10.9 Verificar que codificaciones de caracteres

especficos se definen para todas las

conexiones (por ejemplo, UTF-8).
V11.1 Obsoleto
V11.4 Obsoleto
V11.5 Obsoleto
V11.6 Obsoleto
V11.7 Obsoleto
V11.8 Obsoleto
V11.4 Obsoleto
V13.1 Obsoleto
V13.2 Obsoleto
V13.3 Obsoleto
V13.4 Obsoleto
V13.5 Obsoleto
V13.6 Obsoleto
V13.7 Obsoleto
V13.8 Obsoleto
V13.9 Obsoleto
15.1- Seccin de la lgica de negocios. Combinado 3.0 La mayor parte de la seccin

15.7 15 se ha fusionado en 15.8 y
15.9
15.10.
15.11 Verificar que la aplicacin se protege de los Duplicar 3.0 Requisito de duplicados.
riesgos asociados con la suplantacin de Capturado por V1.6
identidad, manipulacin, repudio, revelacin
de informacin y elevacin de privilegios

(STRIDE).
16.4 Verificar que no se utilizan parmetros Se traslad 3.0 Se traslad a V16.2

obtenidos de fuentes no confiables en la
manipulacin de los nombres de archivo,
rutas de acceso o cualquier objeto de
sistema de archivo sin ser la primera
cannica y entrada validada para prevenir
ataques de inclusin de archivo local.
17.1 Verificar que el cliente valide certificados SSL Obsoleto 3.0 Requisito duplicado. El
requisito general se
encuentra ya capturado por
V10.
Obsoleto
V17.7
Obsoleto
V17.8
Obsoleto
V17.10
Obsoleto
V17.11
Obsoleto
V17.12
Obsoleto
V17.13
Obsoleto
V17.14
Obsoleto
V17.15
Obsoleto
V17.16
Obsoleto
V17.17
Obsoleto
V17.18
Obsoleto
V17.19
Obsoleto
V17.20
Obsoleto
V17.22

Obsoleto
V17.23
Obsoleto
V17.24

Apndice B: Glosario
Control de acceso una forma de restringir el acceso a archivos, funciones de
referencias, URLs y datos basados en la identidad de los usuarios o grupos a que
pertenecen.
Address Space Layout Randomization (ASLR) (ASLR) una tcnica para ayudar a
proteger contra ataques de desbordamiento de bfer.
Aplicaciones de seguridad- La seguridad a nivel de aplicacin se centra en el anlisis
de los componentes que conforman la capa de aplicacin del -Modelo de Referencia
de Interconexin de sistema abierto (modelo OSI), en lugar de centrarse en por
ejemplo el sistema operativo subyacente o redes conectadas.
Verificacin de seguridad en aplicaciones, la evaluacin tcnica de una aplicacin
contra el ASVS.
Informe de verificacin de seguridad de aplicacin un informe que documenta los
resultados generales y anlisis de apoyo producido por el verificador para una
aplicacin particular.
Autenticacin: verificacin de la identidad reivindicada de usuario de una aplicacin.
Verificacin automatizada el uso de herramientas automatizadas (herramientas
de anlisis dinmico, las herramientas de anlisis esttico o ambos) que utilizan
firmas de vulnerabilidad para encontrar problemas.
Puertas traseras un tipo de cdigo malicioso que permite el acceso no autorizado a
una aplicacin.
Lista negra una lista de datos u operaciones que no se permiten, por ejemplo, una
lista de caracteres que no se permite como entrada.
Hojas de Estilos en Cascada (CSS) - un lenguaje de hoja de estilo utilizado para
describir la semntica de la presentacin del documento escrito en un lenguaje de
marcado, como HTML.
Autoridad de certificacin (CA) una entidad que emite los certificados digitales.

Seguridad de las comunicaciones, la proteccin de datos de aplicaciones cuando se
transmite entre los componentes de aplicacin, entre clientes y servidores y entre
sistemas externos y la aplicacin.
Componente una unidad independiente de cdigo, con interfaces de red y disco
asociadas que se comunica con otros componentes.
Cross-Site Scripting (XSS) una vulnerabilidad de seguridad se encuentra
tpicamente en aplicaciones que permiten la inyeccin de secuencias de comandos
de cliente en contenido web.
Mdulo criptogrfico Hardware, software o firmware que implementa algoritmos
criptogrficos o genera claves criptogrficas.
Ataques de denegacin de servicio (DoS) la inundacin de una aplicacin con ms
peticiones que puede manejar.
Verificacin del diseo la evaluacin tcnica de la arquitectura de seguridad de
una aplicacin.
Verificacin dinmica el uso de herramientas automatizadas que utilizan firmas de
vulnerabilidad para encontrar problemas durante la ejecucin de una aplicacin.
Huevos de Pascua un tipo de cdigo malicioso que no se ejecuta hasta que se
produzca un evento de entrada de usuario especfico.
Sistemas externos una aplicacin de servidor o servicio que no es parte de la
aplicacin.
FIPS 140-2, un estndar/norma que puede utilizarse como base para la verificacin
del diseo y aplicacin de mdulos criptogrficos
Identificador nico global (GUID) un nmero de referencia nico utilizado como
un identificador de software.
Lenguaje de marcado de hipertexto (HTML) el lenguaje de marcado principal para
la creacin de pginas web y otra informacin mostrada en el navegador web.
Hyper Text Transfer protocolo (HTTP) un protocolo de aplicacin para sistemas de
informacin distribuido, colaborativo hipermedia. Es la base de datos de
comunicacin de la World Wide Web.

Validacin de entrada la canonizacin y la validacin de entrada de usuario no es
de confianza.
Protocolo ligero de acceso a directorios (LDAP) un protocolo de aplicacin para el
acceso y mantenimiento de servicios de informacin de directorio distribuida sobre
una red.
Cdigo malicioso cdigo introducido en una aplicacin durante su desarrollo
desconocido al dueo de la aplicacin, que elude la poltica de seguridad de la
aplicacin. No es lo mismo un software malicioso a un virus o un gusano!
Malware cdigo ejecutable que se introduce en una aplicacin en tiempo de
ejecucin sin el conocimiento del usuario de la aplicacin o el administrador.
Proyecto Abierto de Seguridad en aplicacin Web (OWASP) es una comunidad
libre y abierta en todo el mundo enfocada en mejorar la seguridad de software en
aplicaciones. Nuestra misin es hacer visible, la seguridad de aplicaciones para
que personas y organizaciones pueden tomar decisiones informadas sobre los
riesgos de seguridad de la aplicacin. Ver: http://www.owasp.org/
Codificacin de salida la canonizacin y la validacin de solicitud de salida para los
navegadores Web y sistemas externos.
Informacin de identificacin personal (IPI) es informacin que puede utilizarse
por s solo o con otra informacin para identificar, contactar o localizar a una sola
persona, o para identificar a un individuo en contexto.
Validacin Positiva vase lista blanca.
Arquitectura de seguridad una abstraccin del diseo de una aplicacin que
identifica y describe los controles de seguridad sobre dnde y cmo se utilizan,
identifica y describe la ubicacin y la sensibilidad de los datos de usuario y la
aplicacin.
Configuracin de seguridad la configuracin de tiempo de ejecucin de una
aplicacin que afecta a cmo se utilizan los controles de seguridad.
Control de seguridad una funcin o componente que realiza una comprobacin de
seguridad (por ejemplo, una verificacin de control de acceso) o cuando resultados

llamados resultan en efecto de seguridad (por ejemplo, generando un registro de
auditora).
SQL Injection (SQLi) una tcnica de inyeccin de cdigo utilizada para atacar
aplicaciones de datos, en que se insertan sentencias SQL maliciosas en un punto de
entrada.
Verificacin esttica el uso de herramientas automatizadas que utilizan firmas de
vulnerabilidad para encontrar problemas en el cdigo fuente de la aplicacin.
Objetivo de la verificacin (TOV) si usted est realizando una verificacin de
seguridad en la aplicacin segn los requisitos del ASVS, la verificacin ser de un
uso particular. Esta aplicacin se llama "El objetivo de la verificacin" o simplemente
el TOV.
Modelado de Amenazas una tcnica que consiste en desarrollar cada vez ms
arquitecturas refinadas de seguridad para identificar agentes de amenaza, las zonas
de seguridad, controles de seguridad y recursos tcnicos y de negocios importantes.
Seguridad de capa de transporte protocolos criptogrficos que proporcionan la
seguridad de las comunicaciones por Internet
Fragmentos de URL/URI/URL un identificador uniforme de recursos es una cadena
de caracteres utilizado para identificar un nombre o un recurso web. Un localizador
uniforme de recursos a menudo se utiliza como una referencia a un recurso.
Aceptacin la prueba del usuario (UAT) tradicionalmente un entorno de prueba
que se comporta como el entorno de produccin donde se realizan todas las pruebas
de software antes de desplegar la aplicacin en vivo.
Verificador la persona o equipo que se est revisando una aplicacin contra los
requisitos del ASVS.
Lista blanca una lista de datos permitidos u operaciones, por ejemplo, una lista de
caracteres permitidos para realizar la validacin de entrada.
XML un lenguaje de marcado que define un conjunto de normas de codificacin de
documentos.

Anexo C: Referencias
Los siguientes proyectos de OWASP son muy probablemente tiles para los
usuarios/adoptantes de esta norma:
Gua de pruebas de OWASP

https://www.owasp.org/index.php/OWASP_Testing_Project
Gua de revisin de cdigo de OWASP
http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
Cheat Sheets de OWASP
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
Controles proactivos de OWASP
https://www.owasp.org/index.php/OWASP_Proactive_Controls
OWASP Top 10
https://www.owasp.org/index.php/Top_10_2013-Top_10
OWASP Mobile Top 10
https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-
_Top_Ten_Mobile_Risks
Del mismo modo, los siguientes sitios web probablemente sean de utilidad para los
usuarios/adoptantes de esta norma:
MITRE Common Weakness Enumeration

http://cwe.mitre.org/
PCI Security Standards Council
https://www.pcisecuritystandards.org
PCI Data Security Standard (DSS) v3.0 Requirements and Security Assessment
Procedures
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Apndice D: Correlacin con otras normas
PCI DSS 6.5 se deriva de la OWASP Top 10 2004/2007, con algunas extensiones recientes del
proceso. El ASVS es un superconjunto estricto del OWASP Top 10 2013 (154 artculos a 10
artculos), as que todas las cuestiones cubiertas por OWASP Top 10 y PCI DSS 6.5.x son
manejadas finamente por requisitos de control ASVS. Por ejemplo, Prdida de
autenticacin y gestin de sesiones conecta exactamente a las secciones de autenticacin
V2 y V3 Manejo de la sesin.
La correlacin completa se logra al nivel de verificacin 3, aunque el nivel de verificacin 2

abordar ms los requisitos de PCI DSS 6.5 excepto 6.5.3 y 6.5.4. Problemas de proceso,
tales como PCI DSS 6.5.6, no estn cubiertos por el ASVS.
PCI-DSS 3.0 ASVS 3.0 Descripcin
6.5.1 fallas de inyeccin, 5.11, 5.12, 5.13, 8.14, 16.2 Correlacin exacta.
particularmente de inyeccin SQL.
Tambin se consideran fallas de
inyeccin de comandos del
sistema operativo y LDAP, XPath,
as como otras fallas de inyeccin
6.5.2 Desbordamientos de buffer 5.1 Correlacin exacta
6.5.3 Almacenamiento v7 - todos Correlacin completa de nivel 1

criptogrfico inseguro
6.5.4 Comunicaciones Inseguras v10 - todos Correlacin completa de nivel 1
6.5.5 Manejo incorrecto de 3.6, 7.2, 8.1, 8.2 Correlacin exacta

errores
6.5.7 Cross-site scripting (XSS) 5.16, 5.20, 5.21, 5.24, 5.25, 5.26, ASVS desglosa XSS en varios
5.27, 11.4,11.15 requisitos destacando la
complejidad de la defensa XSS, en
especial para aplicaciones legadas
6.5.8 Controles de acceso v4 - todos Correlacin completa de nivel 1

inapropiados (como referencias
directas a objetos inseguros, no
restringir acceso URL, el salto de
directorio y falta restringir acceso
de usuario a las funciones).

6.5.9 Falsificacin de peticiones 4.13 Correlacin exacta. ASVS
en sitios cruzados (CSRF). considera la defensa de CSRF un
aspecto de control de acceso.
6.5.10 Prdida de autenticacin y v2 y v3 - todos Correlacin completa de nivel 1

gestin de sesiones.

Estándar de Verificación de Seguridad en Aplicaciones 3.0.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estándar de Verificación de Seguridad en Aplicaciones 3.0.1

Uploaded by

Copyright:

Available Formats

Estndar de Verificacin de Seguridad en

UTILIZANDO EL ESTNDAR DE VERIFICACIN DE SEGURIDAD EN APLICACIONES 9

EVALUANDO QUE EL SOFTWARE HA ALCANZADO UN NIVEL DE VERIFICACIN 18

PROYECTOS OWASP QUE UTILIZAN ASVS 21

REQUISITOS DE VERIFICACIN DETALLADA 22

V1: ARQUITECTURA, DISEO Y MODELADO DE AMENAZAS 23

V2: REQUISITOS DE VERIFICACIN DE AUTENTICACIN 25

V3: REQUISITOS DE VERIFICACIN DE GESTIN DE SESIONES 29

2 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

V4: REQUISITOS DE VERIFICACIN DEL CONTROL DE ACCESO 31

V5: REQUISITOS DE VERIFICACIN PARA MANEJO DE ENTRADA DE DATOS MALICIOSOS 33

V6: CODIFICACIN / ESCAPE DE SALIDAS DE DATOS 37

V7: REQUISITOS DE VERIFICACIN PARA LA CRIPTOGRAFA EN EL ALMACENAMIENTO 38

V8: REQUISITOS DE VERIFICACIN DE GESTIN Y REGISTRO DE ERRORES 40

V9: REQUISITOS DE VERIFICACIN DE PROTECCIN DE DATOS 42

V10: REQUISITOS DE VERIFICACIN DE SEGURIDAD DE LAS COMUNICACIONES 45

V11: REQUISITOS DE VERIFICACIN DE CONFIGURACIN DE SEGURIDAD HTTP 48

V12: REQUISITOS DE VERIFICACIN DE CONFIGURACIN DE SEGURIDAD 50

V13: REQUISITOS DE VERIFICACIN PARA CONTROLES MALICIOSO 51

Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 3

V15: REQUISITOS DE VERIFICACIN PARA LGICA DE NEGOCIOS 53

V16: REQUISITOS DE VERIFICACIN DE ARCHIVOS Y RECURSOS 54

V17: REQUISITOS DE VERIFICACIN MVIL 56

V18: REQUISITOS DE VERIFICACIN DE SERVICIOS WEB 58

V 19. REQUISITOS DE CONFIGURACIN 60

APNDICE A: QU SUCEDI CON 62

APNDICE D: CORRELACIN CON OTRAS NORMAS 74

4 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

El estndar de verificacin de seguridad en aplicaciones es una lista de requerimientos de

Copyright 2008 2017 Fundacin OWASP. Este documento es

Versin 3.0, 2015

Lderes de Proyecto Autores Lderes Revisores y Colaboradores

Versin 2.0, 2014

Lderes de Proyecto Autores Lderes Revisores y Colaboradores

Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 5

Versin 1.0, 2009

Lderes de Proyecto Autores Lderes Revisores y Colaboradores

6 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

ASVS v3.0 es la culminacin de un esfuerzo comunitario y de retroalimentacin por parte de

Es esperable que este estndar no genere un 100% de consenso. El Anlisis de riesgo es

Qu hay de nuevo en la versin 3.0?

Hemos proporcionado la correspondencia con el CWE (Diccionario de debilidades comunes).

Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 7

8 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

ayudar a las organizaciones en el desarrollo y mantenimiento aplicaciones seguras

Niveles de verificacin de seguridad de aplicaciones

El Estndar de Verificacin de Seguridad en Aplicaciones define tres niveles de verificacin

ASVS nivel 1 se encuentra dirigido a todo tipo de software.

Figura 1 Niveles del Estndar de Verificacin de Seguridad en Aplicaciones de OWASP

Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 9

Una de las mejores maneras de emplear el Estndar de Verificacin de Seguridad en

Una aplicacin alcanza ASVS nivel 1 (u oportunista) si se defiende adecuadamente contra

Las amenazas a la aplicacin probablemente provendrn de atacantes que utilizan tcnicas

Una aplicacin alcanza ASVS nivel 2 (o estndar), si se defiende adecuadamente contra la

El Nivel 2 asegura que controles de seguridad se encuentran en el lugar adecuado, son

10 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

Una aplicacin en el nivel 3 de ASVS, requiere un anlisis de mayor profundidad,

Aplicando ASVS en la prctica

Diferentes amenazas poseen diferentes motivaciones. Algunas industrias tienen activos de

A continuacin, se proporcionan recomendaciones con respecto a los niveles de ASVS

Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 11

12 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1

Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1 13

14 Estndar de Verificacin de Seguridad en Aplicaciones 3.0.1