Dentro de la comunidad de seguridad de la información, el proyecto OWASP (The Open Web Application Security Project - https://www.owasp.org) tiene un amplio reconocimiento debido a sus aportes en pro de la mejora de los controles para la protección de aplicaciones web. Uno de sus proyectos más importantes es el “OWASP Top Ten Project” (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), que, de forma periódica, lista los 10 riesgos más críticos en este tipo de aplicaciones. Este listado se establece con base en múltiples propuestas de firmas especializadas en seguridad de aplicaciones y de entrevistas a más de 500 individuos, cuyos datos son seleccionados y priorizados de acuerdo con estimaciones consensuadas de explotabilidad, detectabilidad e impacto, tanto técnico como al negocio.
Figura 1. Variables para el cálculo del riesgo en aplicaciones (Fuente: OWASP)
La versión más reciente de este listado - OWASP Top 10 2017 https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf - fue publicada el 20 de noviembre de 2017. Esta nueva versión, a diferencia de su predecesora, la versión 2013 (https://www.owasp.org/images/5/5f/OWASP_Top_10_-_2013_Final_-_Espa%C3%B1ol.pdf), ha tenido en cuenta el impacto de nuevas tecnologías en la industria y los cambios de arquitectura en aplicaciones web, tales como el uso de microservicios escritos en node.js y Spring Boot y el uso de marcos de trabajo web basados en JavaScript (Angular, Bootstrap, Electron y React).
De acuerdo con ello, la priorización de riesgos en esta nueva versión 2017 ha quedado de la siguiente manera, en comparación con la versión del 2013:
Figura 2. Comparativo de los riesgos del OWASP Top Ten de 2013 y de 2017 (Fuente: OWASP)
Como se puede observar, se han priorizado tres nuevos riesgos (A4, A8 y A10), dos han sido fusionados (A4 y A7 del 2013 en el A5 de 2017) y dos han sido retirados (A8 y A10 del 2013) debido al bajo porcentaje de aplicaciones afectadas hoy en día. Todo lo anterior demuestra que, a pesar del gran esfuerzo realizado para la protección de la infraestructura de aplicaciones web, las amenazas constantemente van evolucionando, quizás más rápido que la propia tecnología.
OWASP Top Ten y PCI DSS
Desde sus primeras versiones, PCI DSS siempre citado a la OWASP como referente para la definición de directrices de codificación segura. Por ello, en el requisito 6.5 “Aborde las vulnerabilidades de codificación comunes en los procesos de desarrollo de software” se citan las guías de la OWASP como mejores prácticas de la industria a ser empleadas para estas acciones, en conjunción con las guías del CERT (https://www.cert.org/secure-coding/publications/index.cfm) y del SANS CWE Top 25 (http://cwe.mitre.org/top25/).
Teniendo en cuenta la dinámica en términos de riesgos en las aplicaciones web, el PCI SSC fue bastante precavido y por ello dejó en claro que, en el caso de actualización de las mejores prácticas de la industria para la gestión de las vulnerabilidades, éstas deberían primar sobre las identificadas por el propio estándar.
Figura 3. Requisito 6.5 de PCI DSS
Por otro lado, también se deja en claro lo siguiente:
“A medida que cambian las prácticas de codificación segura aceptadas por la industria, las prácticas de codificación de las organizaciones y la capacitación de los desarrolladores se deben actualizar para abordar nuevas amenazas, por ejemplo, ataques para extraer la memoria.
Las vulnerabilidades identificadas en los Requisitos 6.5.1 al 6.5.10 proporcionan un punto de partida mínimo. Es responsabilidad de la organización informarse sobre las últimas tendencias en vulnerabilidades e incorporar las medidas apropiadas en cuanto a las prácticas de codificación segura”.
Las vulnerabilidades descritas en los requisitos 6.5.1 al 6.5.10 de PCI DSS hacen referencia a los controles mínimos que se deben implementar y que las organizaciones deben incorporar dentro de sus prácticas de codificación segura correspondientes a la tecnología particular de su entorno. A continuación, se relacionan dichos requisitos de PCI DSS y su correspondencia con los Top Ten de la OWASP de los años 2013 y 2017:
Req.
|
Descripción
|
Referencia en OWASP Top Ten 2013
|
Referencia en OWASP Top Ten 2017
|
6.5.1
|
Errores de inyección, en especial,
errores de inyección SQL. También considere los errores de inyección de
comandos de OS, LDAP y Xpath, así como otros errores de inyección.
|
A1:2013
|
A1:2017
|
6.5.2
|
Desbordamiento de buffer
|
-
|
-
|
6.5.3
|
Almacenamiento cifrado inseguro
|
A6:2013
|
A3:2017
|
6.5.4
|
Comunicaciones inseguras
|
A6:2013
|
A3:2017
|
6.5.5
|
Manejo inadecuado de errores
|
A5:2013
A6:2013
|
A3:2017
A6:2017
|
6.5.6
|
Todas las vulnerabilidades de “alto riesgo” detectadas en
el proceso de identificación de vulnerabilidades
|
A9:2013
|
A9:2017
|
6.5.7
|
Lenguaje de comandos entre distintos
sitios (XSS)
|
A3:2013
|
A7:2017
|
6.5.8
|
Control de acceso inapropiado
|
A4:2013
A7:2013
A10:2013
|
A5:2017
|
6.5.9
|
Falsificación de
solicitudes entre distintos sitios (CSRF)
|
A8:2013
|
-
|
6.5.10
|
Autenticación y administración de
sesión interrumpidas
|
A2:2013
|
A2:2017
|
Como se puede observar, ninguno de los nuevos riesgos incluidos en la versión 2017 del Top Ten de la OWASP es contemplado por PCI DSS v3.2:
- A4:2017 – XML External Entities (XXE)
- A8:2017 – Insecure Deserialization
- A10:2017 – Insufficient Logging & Monitoring
¿Qué implican estos cambios en el cumplimiento de PCI DSS y cómo se debe proceder?
La priorización de nuevos riesgos a nivel de aplicación previamente no cubiertos por PCI DSS, pero identificados actualmente en la última versión del Top Ten de la OWASP, implica que todas las organizaciones que desarrollen aplicaciones de pago para entornos PCI DSS deben proceder de la siguiente manera:
- Actualizar la documentación vinculada con el SSDLC (Secure Software Development Life Cycle) para que contemplen la totalidad de los riesgos del Top Ten de la OWASP 2017 – Req. 6.3
- Actualizar los criterios empleados en la revisión de código (ya sea si se realiza manualmente o empleando herramientas automatizadas) antes de enviarlo a Producción para que cubran estos nuevos riesgos – Req. 6.3.2
- Actualizar el material de formación en desarrollo seguro incluyendo estos nuevos riesgos y describir sus contramedidas – Req. 6.5
- Proceder a capacitar a los desarrolladores dentro de los ciclos formativos anuales – Req. 6.5
- Si se cuenta con aplicaciones web públicas y dependiendo de la opción empleada para protegerlas contra ataques conocidos, actualizar dichos métodos para que contemplen los riesgos de la OWASP Top Ten 2017:
o Si se emplean herramientas o métodos de evaluación de vulnerabilidades de aplicación automáticos o manuales, éstos deben permitir la identificación de los nuevos riesgos.
o Si se emplea un WAF (Web Application Firewall), esta solución debe ser configurada para que detecte y/o bloquee aquellos ataques vinculados con estos nuevos riesgos.
Finalmente, se recomienda la revisión de otros proyectos interesantes de la OWASP, como OWASP Proactive Controls (https://www.owasp.org/index.php/OWASP_Proactive_Controls), OWASP Application Security Verification Standard (ASVS - https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project), Software Assurance Maturity Model (SAMM - https://www.owasp.org/index.php/OWASP_SAMM_Project) y OWASP Testing Guide (https://www.owasp.org/index.php/OWASP_Testing_Project), así como las guías específicas para desarrolladores del OWASP Cheat Sheet Series (https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series). Se puede encontrar información adicional en los anexos “What’s Next for Developers“, “What’s Next for Security Testers“, “What’s Next for Organizations” y “What’s Next for Application Managers”, que se encuentran al final del documento del Top Ten de 2017.
Autor: David Eduardo Acosta
CISSP Instructor, CISM, CISA, CRISC, CHFI Instructor, CEH, PCI QSA, OPST, BS25999 L.A.
Dpto. de Consultoría
Dpto. de Consultoría
