Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Estándar de Verificación de Seguridad en Aplicaciones 3.0.1 PDF
Estándar de Verificación de Seguridad en Aplicaciones 3.0.1 PDF
Aplicaciones 3.0.1
Versión en español: Abril de 2017
AGRADECIMIENTOS 5
SOBRE EL ESTÁNDAR 5
COPYRIGHT Y LICENCIA 5
INTRODUCCIÓN 7
¿QUÉ HAY DE NUEVO EN LA VERSIÓN 3.0? 7
CASO DE ESTUDIOS 15
CASO DE ESTUDIO 1: ASVS COMO GUÍA DE PRUEBA DE SEGURIDAD 15
ESTUDIO DE CASO 2: UN SDLC SEGURO 16
APÉNDICE B: GLOSARIO 69
ANEXO C: REFERENCIAS 73
Copyright y licencia
En la versión 3.0, hemos añadido varias secciones nuevas, incluyendo configuración, Web
Services, aplicaciones cliente, para hacer la norma más aplicable a aplicaciones modernas,
comúnmente responsive, con amplio uso de interfaces de usuario HTML5 o móvil, llamando
a un conjunto común de Web Services REST, utilizando autenticación SAML.
Hemos reducido también las duplicaciones en la norma, por ejemplo, para asegurarnos de
que un desarrollador móvil no necesite re-testear los mismos elementos varias veces.
Por último, buscamos ayuda en la comunidad con el fin de generar sesiones para la revisión
por pares durante las conferencias de AppSec EU 2015 y una sesión final de trabajo en
AppSec USA 2015 con el fin de incluir una enorme cantidad de comentarios de la
comunidad. Durante la revisión, 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 podría ser una
fuente de confusión. Hemos proporcionado una asignación completa de lo que ha cambiado
en el apéndice A.
Cada nivel ASVS contiene una lista de requerimientos de seguridad. Cada uno de estos
requisitos pueden también corresponderse a funcionalidades específicas de seguridad y
capacidades que deben construirse por los desarrolladores de software.
Nivel 1: Oportunista
Este nivel es apropiado típicamente para aplicaciones donde se requiere escasa confianza
en el uso correcto de los controles de seguridad, o para proporcionar un análisis rápido a un
conjunto de aplicaciones de una organización, o asistir en la elaboración de una lista de
requerimientos de seguridad con prioridades como parte de un esfuerzo de múltiples fases.
Los controles de nivel 1 pueden ser asegurados automáticamente por herramientas o
manualmente sin acceso al código fuente. Consideramos a nivel 1 como el mínimo
requerido para todas las aplicaciones.
Nivel 2: Estándar
Las amenazas para aplicaciones de nivel 2 por lo general están motivados por atacantes los
cuales se centran en objetivos concretos, utilizando herramientas y técnicas efectivas en el
descubrimiento y explotación de vulnerabilidades dentro de las aplicaciones.
Nivel 3: Avanzado
El nivel 3 en ASVS es el más alto nivel de verificación dentro de ASVS. Este nivel está
reservado normalmente para aplicaciones que requieren niveles significativos de
Aunque existen criterios únicos y diferencias en las amenazas para cada sector, una
amenaza común a todos los segmentos o industrias, son los ataques oportunistas. Estos
buscarán cualquier aplicación vulnerable fácilmente explotable. Por esta razón el nivel 1 se
recomienda para toda aplicación. Se sugiere este punto de partida para manejar los riesgos
más fáciles de encontrar. También se recomienda a las organizaciones observar
detenidamente sus riesgos específicos basados en la naturaleza de su negocio.
Por otro lado, el nivel 3 de ASVS se encuentra reservado para aquellos casos en que se
podría poner en peligro la seguridad humana o cuando una violación a la aplicación podría
impactar seriamente y por completo a la organización.
En una Universidad privada en Utah, Estados Unidos, el equipo rojo del campus utiliza el
OWASP ASVS como guía al realizar tests de penetración a aplicaciones. Es utilizado a lo largo
del proceso de pruebas, desde la planificación inicial, definiendo reuniones de orientación
para las actividades de la prueba y como una manera de enmarcar las conclusiones del
informe final entregado a los clientes. El equipo rojo también organiza capacitaciones para
el equipo utilizando el ASVS.
El equipo rojo del Campus realiza tests de penetración de redes y aplicaciones para varios
departamentos del campus como parte de la estrategia de seguridad de la información
general de la Universidad. Durante las reuniones de planificación iniciales, los clientes
suelen ser reticentes a dar autorización para que su aplicación 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 estándar, y que el informe final incluirá cómo
se comporta la aplicación en comparación con el estándar, muchas preocupaciones quedan
inmediatamente aclaradas. Luego, el ASVS es utilizado durante la evaluación para ayudar a
determinar cuánto tiempo y esfuerzo se utilizará en la prueba. Mediante el uso de los
niveles de verificación 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 aplicación en cuestión.
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 verificación que han
sido probados y que se encuentran pendientes, el gerente de proyecto para el equipo puede
observar fácilmente el avance de las pruebas. Esto conduce a mejorar la comunicación con
los clientes y permite al jefe de proyecto gestionar mejor los recursos. Dado que el equipo
rojo está compuesto principalmente de estudiantes, la mayoría de los miembros del equipo
tienen múltiples demandas de su tiempo proveniente de diferentes cursos. Las tareas bien
definidas, basadas en los requisitos de verificación individual o categorías totales, ayudan a
los miembros del equipo a saber exactamente qué debe analizarse y que estos puedan
proporcionar estimaciones precisas sobre cuánto tiempo tardarán para completar las
tareas. La actividad de informar también se beneficia de la clara organización del ASVS,
debido a que los miembros del equipo pueden reportar sus hallazgos antes de continuar
con el siguiente punto del estándar, generando el informe de forma simultánea con la
ejecución de las pruebas de penetración.
El equipo rojo organiza el informe final alrededor de la ASVS, informando del estado de cada
requisito de verificación y proporcionando más detalles cuando sea apropiado. Esto le da
una idea a clientes e interesados de cómo se encuentra su aplicación con respecto al
estándar, lo cual es extremadamente valioso desde el punto de vista del seguimiento pues
permite ver cómo ha mejorado o empeorado la seguridad durante un transcurso de tiempo.
Finalmente, el entrenamiento del equipo rojo ha mejorado con la adopción 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 formación basada en estos criterios
tenía el potencial de ampliar las habilidades de los miembros del equipo, pero no
necesariamente se relacionaban con las actividades básicas del equipo rojo. En otras
palabras, el equipo no consiguía mejorar significativamente en pruebas de penetración.
Después de adoptar el ASVS, el entrenamiento del equipo, se centra ahora en cómo probar
los requisitos de verificación 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.
La compañía "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 sesión en la aplicación. La compañía "start-up" usa ASVS de forma diferente en
comparación a la mayoría - ellos tratan de ver a través de ASVS, recogiendo los requisitos
que se adhieren al sprint actual, y lo agregan directamente a la acumulación del sprint si es
un requisito funcional, o como una limitación a casos de uso existentes si no son
funcionales. Por ejemplo, la adición de la autenticación TOTP (Contraseña de un solo uso
basada en tiempo), junto con las políticas de contraseñas y servicio web que de detección
de ataques de fuerza bruta. En los sprints futuros, los requisitos adicionales se seleccionarán
basados en el criterio "justo a tiempo", o que "no se va a necesitar".
Los desarrolladores utilizan el ASVS como una checklist de revisión por pares, lo que ayuda a
que código inseguro no sea ingresado en el repositorio, y en retrospectiva, desafiar a los
desarrolladores que hayan ingresado algún código en el repositorio que contenga una nueva
característica, 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
verificación automatizada y conjuntos de pruebas de integración, casos de abuso y casos de
Esto no debe inhibir organizaciones para ofrecer dichos servicios de garantía, con tal de que
no pretendan proveer una certificación oficial de OWASP.
Históricamente, los test de penetración y las revisiones de código han incluido hallazgos
“por excepción”. – es decir, el informe final solo se compone de defectos de seguridad. Una
organización certificadora debe incluir en cualquier informe cual fue el alcance de la
verificación (especialmente si un componente clave está fuera de alcance, como la
autenticación SSO), un resumen de resultados de la verificación, incluyendo las pruebas
exitosas y las fallidas, con indicaciones claras de cómo resolver las fallidas.
Es posible realizar una prueba de penetración manual y verificar todos los puntos del nivel
L1 sin necesidad de acceso al código fuente, aunque esta no es una práctica muy utilizada.
Para el nivel L2 se requiere al menos algún acceso a los desarrolladores, documentación,
código y acceso autenticado al sistema. Una cobertura completa de pruebas de penetración
del nivel 3 no es posible, como la mayoría de los problemas adicionales incluyen revisión de
configuración del sistema, revisión de código malicioso, modelado de amenazas y otros
artefactos de prueba de penetración.
Uno de los usos más comunes para el estándar de verificación de seguridad en aplicaciones
es su utilización como un recurso para arquitectos de seguridad. Los dos marcos de la
arquitectura de seguridad, SABSA o TOGAF, carecen de una gran cantidad de información
necesaria para completar por medio de una revisión de arquitectura aspectos de seguridad
de la aplicación. ASVS puede utilizarse mitigar esas carencias permitiendo a los arquitectos
de seguridad elegir controles adecuados para problemas comunes, tales como patrones de
protección de datos y estrategias de validación de entradas de datos.
Muchas organizaciones pueden beneficiarse de la adopción 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 aplicación en un dominio específico. Recomendamos este tipo de combinación o
adaptación del ASVS original mientras se mantiene la trazabilidad, por lo que si una
aplicación ha pasado requisito 4.1, esto significa lo mismo tanto para el refinamiento como
para el estándar a medida que éste evolucione.
El ASVS está diseñado para ser altamente verificable, con la sola excepción de requisitos de
arquitectónicos y de código malicioso. A través de la generación de pruebas unitarias y de
integración (tanto específicas como de fuzzing), la aplicación se aproxima a auto verificase y
validarse con cada construcción. Por ejemplo, se pueden generar pruebas adicionales para
el paquete de pruebas para el control de acceso, para testear el parámetro nombre de
usuario para nombres de usuario comunes, enumeración de cuenta, ataques de fuerza
Estándar de Verificación de Seguridad en Aplicaciones 3.0.1 19
bruta, inyección LDAP y SQL y XSS. Asimismo, se deben incluir pruebas al parámetro de
contraseña para las más comunes, su longitud, inyección de byte nulo, eliminación del
parámetro, XSS, enumeración de cuentas y mucho más.
ASVS también puede utilizarse para definir características de software seguro. Muchos
cursos de «codificación segura» son simplemente cursos éticos de hacking con un ligero
toque de consejos sobre codificación. Esto no ayuda a los desarrolladores de sistemas. En
cambio, cursos de desarrollo seguro pueden usar la guía ASVS con un fuerte enfoque en los
controles pro-activos en esta, en lugar de cosas negativas del OWASP Top 10.
https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework
Para entrenar desarrolladores en la escritura de código seguro - El proyecto SKF es una
aplicación completamente gratis escrita en Python-Flask que utiliza el estándar de
verificación de seguridad OWASP para aplicaciones, pensada para entrenar en la escritura
de código seguro desde su diseño.
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
OWASP Zed (ZAP) es una herramienta de fácil uso e integrada para la búsqueda de
vulnerabilidades en aplicaciones web. Está diseñada tanto para ser utilizado por personas
con amplia experiencia en seguridad, así como desarrolladores y testers funcionales que son
nuevos en pruebas de penetración. 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
metodologías ágiles y procesos de desarrollo formales. Es un lenguaje agnótico de la
tecnología y la plataforma. El contenido de Cornucopia fue seleccionado en base a la
estructura de la Guía Práctica de Codificación Segura de OWASP - guía de referencia rápida
(SCP), considerando adicionalmente el estándar de verificación de seguridad de OWASP
para aplicaciones, la guía de pruebas de OWASP y los principios de programación segura de
David Rook.
V2. Autenticación
V10. Comunicaciones
V17. Móvil
Asegurar que una aplicación verificada satisfaga los siguientes requisitos de alto nivel:
• Nivel 1, los componentes de la aplicación son identificados y tienen una razón de ser.
• Nivel 2, se ha definido la arquitectura y el código se adecúa a ésta.
• Nivel 3, la arquitectura y el diseño son los indicados, se utilizan y resultan eficaces.
Requisitos
# Descripción 1 2 3 Desde
Referencias
Autenticación es el acto de establecer o confirmar, algo (o alguien) como auténtico, esto es,
que lo que reclama sobre aquello es verdadero. Se debe asegurar que la aplicación satisface
los siguientes requisitos de alto nivel:
Requisitos
# Descripción 1 2 3 Desde
Referencias
Uno de los componentes básicos de cualquier aplicación 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 interacción entre un usuario y la aplicación basada en la web.
Requisitos
# Descripción 1 2 3 Desde
Referencias
Autorización es el concepto de permitir acceso a los recursos únicamente a aquellos que les
ha sido permitido utilizarlos. Se debe asegurar que la aplicación verificada satisface los
siguientes requisitos de alto nivel:
Requisitos
# Descripción 1 2 3 Desde
Referencias
. Se debe asegurar que la aplicación verificada satisface los siguientes requisitos de alto
nivel:
Requisitos
Desd
# Descripción 1 2 3
e
Referencias
Asegure que una aplicación verificada satisfaga los siguientes requisitos de alto nivel:
• Que todos los módulos criptográficos fallen de forma segura y que los errores sean
gestionados correctamente.
• Que se utilice un generador de números aleatorios adecuado cuando se requiere la
aleatoriedad.
• Que el acceso a claves se gestiona de forma segura.
Requisitos
# Descripción 1 2 3 Desde
Referencias
Los registros de bitácora de alta calidad a menudo contienen datos confidenciales y también
deben ser protegidos según las leyes de privacidad de datos o directivas. Esto debe incluir:
Si los registros contienen datos privados o confidenciales, cuya definición varía de país a
país, éstos se convierten en parte de la información sensible y por lo tanto resulta muy
atractiva para los atacantes.
Requisitos
# Descripción 1 2 3 Desde
Referencias
Las aplicaciones web deben asumir que todos los dispositivos de un usuario puedan ser
comprometidos de alguna manera. Cuando una aplicación transmite o almacena
información sensible dentro de dispositivos inseguros, como equipos compartidos,
teléfonos y tabletas, la aplicación es responsable de que los datos almacenados en estos
dispositivos sean cifrados y no pueden ser fácilmente o ilícitamente obtenidos, alterados o
divulgados.
Requisitos
# Descripción 1 2 3 Desde
Se debe asegurar que la aplicación verificada satisfaga los siguientes requisitos de alto nivel:
Requisitos
# Descripción 1 2 3 Desde
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 producción haya sido 3.0
enviada a una lista precargada de dominios de Strict
Transport Security(STS) mantenidos por proveedores de ✓
navegadores web. Para obtener más información, vea las
referencias abajo.
10.13 Asegurar que foward secrecy se esté utilizando para mitigar 3.0
✓ ✓ ✓
que atacantes pasivos puedan grabar el tráfico.
Referencias
Asegure que la aplicación verificada satisfaga los siguientes requisitos de alto nivel:
Requisitos
# Descripción 1 2 3 Desde
Referencias
Asegure que la aplicación verificada satisfaga los siguientes requisitos de alto nivel:
El código malicioso es extremadamente raro difícil de detectar. La revisión manual línea por
línea del código puede ayudar a encontrar bombas lógicas, pero incluso el más
experimentado revisor de código tendrá que esforzarse para encontrar código malicioso
aunque sepa que existe.
Requisitos
# Descripción 1 2 3 Desde
Referencias
• http://www.dwheeler.com/essays/apple-goto-fail.html
Asegure que la aplicación verificada satisfaga los siguientes requisitos de alto nivel:
Requisitos
# Descripción 1 2 3 Desde
Referencias
Asegure que la aplicación verificada satisfaga los siguientes requisitos de alto nivel:
Requisitos
# Descripción 1 2 3 Desde
Referencias
Esta sección contiene controles específicos para aplicaciones móviles. Estos controles han
sido de-duplicados de la versión 2.0, por lo que deben tomarse en conjunto con el resto de
las secciones de los niveles correspondientes de Verificación ASVS.
• Deben tener el mismo nivel de controles de seguridad tanto en el cliente móvil como
en el servidor, mediante la aplicación de controles de seguridad en un entorno de
confianza.
• Activos de Información 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
# Descripción 1 2 3 Desde
Referencias
Asegúrese de que la aplicación verificada, de utilizar servicios web REST o SOAP posean:
Requisitos
# Descripción 1 2 3 Desde
18.5 Verificar que los servicios web basados en SOAP son 3.0.1
compatibles con el perfil básico de
interoperabilidad de servicios Web (WS-I) como ✓ ✓ ✓
mínimo. Esencialmente, eso implica compatibilidad
con cifrado TLS.
Referencias
Requisitos
# Descripción 1 2 3 Desde
Referencias
2.5 Verificar que todos los controles de Combinado 3.0 Generalizado para incluir
autenticación (incluyendo las bibliotecas que todos los controles de
requieren servicios de autenticación seguridad y se trasladó a 1.10
externos) tengan una implementación
centralizada.
2.10 Verificar que autenticación sea requerida Obsoleto 2.0 Se quita el control debido a
antes de que se permitan cualquier que la re- autenticación se
operación sensible específicas de la observa raramente.
aplicación.
2.14 Verificar que todas las credenciales de Actualizado 2.0 Se convirtió en V2.21
autenticación para acceder a servicios
externos a la aplicación se encuentren
cifradas y almacenadas en un lugar protegido
(no en código fuente).
2.15 Verificar que todo el código de aplicación o Se trasladó 2.0 Se trasladó a V13 - código
uso de controles de autenticación no es este malicioso
afectado por cualquier código malicioso.
2.30 Verificar que si la aplicación permite a los Obsoleto 3.0.1 Muy ambiguo para ser
usuarios autenticarse, se provee un probado, de hecho, es un
mecanismo de autenticación seguro resumen de los
requerimientos de V2
3.13 Verificar que todo el código de aplicación o Se trasladó 2.0 Se trasladó a V13 - código
uso de controles de gestión de sesión no se malicioso
encuentre afectado por código malicioso
3.14 Verificar que los tokens de sesión Actualizado 3.0 Se trasladó a 3.13
autenticados usando cookies están
protegidos por el uso de "HttpOnly".
3.15 Verificar que los tokens de sesión Actualizado 3.0 Se trasladó a 3.13
autenticados usando cookies están
protegidos con el atributo "secure".
4.2 Verificar que los usuarios sólo pueden Actualizado 3.0 Contemplado en 4.1
acceder a URLs seguras que poseen una
autorización específica.
4.3 Verificar que los usuarios sólo puedan Actualizado 3.0 Contemplado en 4.1
acceder a los archivos de datos asegurados
para los que poseen una autorización
específica.
4.13 Compruebe que las limitaciones en entrada y Se trasladó 3.0 Se trasladó a la lógica de
acceso impuestas por reglas de negocios negocio de V15
sobre la aplicación (como límites de
transacciones diarias o secuenciación de las
tareas) no sean sobrepasadas.
4.15 Verificar que todo el código de aplicación o Se trasladó 2.0 Se trasladó a controles
uso de controles de acceso no se vea maliciosos V13
afectado por cualquier código malicioso.
5.2 Verificar que un patrón de validación positivo Obsoleto 2.0 Removido debido a que es
es definido y aplicado a todas las entradas de demasiado difícil 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 difícil de aplicar en
todas las fuentes de entrada la mayoría de los lenguajes de
programación
5.7 Verificar que todos los fallos de validación Obsoleto 3.0 Removido, debido a que
de entrada se registren. crearía muchos registros
5.8 Verificar que toda entrada de datos es Obsoleto 3.0 Removido ya que el tipo 1 JSP
canónica para todos los decodificadores tecnología específica no es un
downstream o intérpretes antes de la problema para los marcos de
validación. desarrollo más modernos
5.9 Verificar que todos los controles de Se trasladó 2.0 Se trasladó a controles
validación de entrada dedatos no sean maliciosos V13
afectados por cualquier código malicioso
5.14 Verificar que el entorno de ejecución 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.19 Verificar que para cada tipo de Combinado 3.0 Generalizado para incluir
codificación/escape de salida realizado por la todos los controles de
aplicación, 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
criptográficas utilizadas para proteger modernas de respuesta
secretos del usuario de la aplicación se rápida y móvil incluyen esto
ejecutan del lado del servidor por diseño
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 aplicación almacenada como
texto simple en el disco que se utiliza para
proteger el acceso a la información de
configuración de seguridad).
7.4 Verificar que los hashes de contraseñas son Se trasladó 2.0 Se trasladó a V2.13
salados cuando sean creados
7.5 Verificar que se registran en una bitácora las Obsoleto 2.0 Creación de registros log
fallas de módulo criptográfico innecesarios que no son
revisados nunca es
contraproducente
8.3 Verificar que todos los controles de registro Se trasladó 3.0 Se convirtió en un control
se ejecuten en el servidor. arquitectónico más genérico
en V1.13
8.9 Verifique que haya una implementación Se trasladó 3.0 Se convirtió en un control
única de registro de bitácora a nivel de la arquitectónico más genérico
aplicación que sea utilizada por el software. en V1.13
8.11 Verificar que una herramienta de análisis del Obsoleto 3.0 Removido ya que no requiere
registros de bitácora se encuentre disponible de software seguro
al analista el cual le permita buscar eventos
basados en combinaciones de criterios de
búsqueda en todos los campos en el formato
de registro log compatibles con este sistema.
8.12 Verificar que todo el código de la aplicación o Se trasladó 2.0 Se trasladó a controles
uso de controles de registro de bitácora y maliciosos V13
control de errores no sea afectado por
cualquier código malicioso.
8.15 Verificar que el registro de bitácora se realice Obsoleto 3.0 Eliminado debido a que es
antes de ejecutar la transacción. Si el registro control demasiado detallado
de bitácora no tuvo éxito (p. ej. disco que sólo sería aplicable a un
completo, permisos insuficientes) la pequeño porcentaje de todas
aplicación 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 conexión insegura HTTP
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.11 Verificar que la aplicación se protege de los Duplicar 3.0 Requisito de duplicados.
riesgos asociados con la suplantación de Capturado por V1.6
identidad, manipulación, repudio, revelación
de información y elevación de privilegios
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.24
Del mismo modo, los siguientes sitios web probablemente sean de utilidad para los
usuarios/adoptantes de esta norma:
6.5.1 fallas de inyección, 5.11, 5.12, 5.13, 8.14, 16.2 Correlación exacta.
particularmente de inyección SQL.
También se consideran fallas de
inyección de comandos del
sistema operativo y LDAP, XPath,
así como otras fallas de inyección
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