1. La explotación del control de acceso es una habilidad esencial de los atacantes.
2. Exposición de Datos Sensibles
2.1. App. Específica, Explotabilidad
2.1.1. En lugar de atacar la criptografía, los atacantes roban claves, ejecutan ataques Man in the Middle o roban datos en texto plano del servidor, en tránsito, o desde el cliente.
2.2. Prevalencia, detectabilidad
2.2.1. El error más común es simplemente no cifrar los datos sensibles. Cuando se emplea criptografía, es común la generación y gestión de claves, algoritmos, cifradores y protocolos débiles.
2.3. Técnico, ¿negocio?
2.3.1. Típicamente, esta información incluye Información Personal Sensible (PII) como registros de salud, datos personales, credenciales y tarjetas de crédito, que a menudo requieren mayor protección, según lo definido por las leyes o reglamentos como el PIBR de la UE o las leyes locales de privacidad.
2.4. ¿La aplicación es vulnerable?
2.4.1. contraseñas, números de tarjetas de crédito, registros médicos, información personal y datos sensibles del negocio requieren protección adicional, especialmente si se encuentran en el ámbito de aplicación de leyes de privacidad
2.4.1.1. Cómo se previene
2.4.1.1.1. Identifique qué información es sensible de acuerdo a las regulaciones, leyes o requisitos del negocio y del país.Aplique los controles adecuados para cada clasificación.
3. Inyección
3.1. App. Específica, Explotabilidad: 3
3.1.1. Casi cualquier fuente de datos puede ser un vector de inyección: variables de entorno, parámetros, servicios web externos e internos, y todo tipo de usuarios.
3.2. Prevalencia, Detectabilidad: 3
3.2.1. Estos defectos son muy comunes, particularmente en código heredado
3.3. Técnico, ¿Negocio?
3.3.1. Una inyección puede causar divulgación, pérdida o corrupción de información, pérdida de auditabilidad, o denegación de acceso.
3.4. ¿LA APLICACION ES VULNERABLE?
3.4.1. • Los datos suministrados por el usuario no son validados, filtrados o sanitizados por la aplicación. • Se invocan consultas dinámicas o no parametrizadas, sin codificar los parámetros de forma acorde al contexto. • Se utilizan datos dañinos dentro de los parámetros de búsqueda en consultas Object-Relational Mapping (ORM), para extraer registros adicionales. • Los datos dañinos se usan directamente o se concatenan, de modo que el SQL o comando resultante contiene datos y estructuras con consultas dinámicas.
3.4.1.1. ¿Cómo se previene?
3.4.1.1.1. La opción preferida es utilizar una API segura, que evite el uso de un intérprete por completo y proporcione una interfaz parametrizada. Realice validaciones de entradas de datos en el servidor, utilizando "listas blancas"
4. Pérdida de Control de Acceso
4.1. App. Específica, Explotabilidad
4.2. Prevalencia, detectabilidad
4.2.1. Las debilidades del control de acceso son comunes debido a la falta de detección automática y a la falta de pruebas funcionales efectivas por parte de los desarrolladores de aplicaciones.
4.3. Técnico, ¿negocio?
4.3.1. El impacto técnico incluye atacantes anónimos actuando como usuarios o administradores
4.4. ¿La aplicación es vulnerable? Las restricciones de control de acceso implican que los usuarios no pueden actuar fuera de los permisos previstos. Típicamente, las fallas conducen a la divulgación, modificación o destrucción de información no autorizada de los datos, o a realizar una función de negocio fuera de los límites del usuario.
4.4.1. Cómo se previene El control de acceso sólo es efectivo si es aplicado del lado del servidor o en Server-less API, donde el atacante no puede modificar la verificación de control de acceso o los metadatos.
5. Cross-Site Scripting (XSS)
5.1. App. Específica, Explotabilidad
5.1.1. Existen herramientas automatizadas que permiten detectar y explotar las tres formas de XSS, y también se encuentran disponibles kits de explotación gratuitos.
5.2. Prevalencia, detectabilidad
5.2.1. XSS es la segunda vulnerabilidad más frecuente en OWASP Top 10, y se encuentra en alrededor de dos tercios de todas las aplicaciones.
5.3. Técnico, ¿negocio?
5.3.1. El impacto de XSS es moderado para el caso de XSS Reflejado y XSS en DOM, y severa para XSS Almacenado, que permite ejecutar secuencias de comandos en el navegador de la víctima,
6. Uso de Componentes con Vulnerabilidades Conocidas
6.1. App. Específica, Explotabilidad
6.1.1. Es sencillo obtener exploits para vulnerabilidades ya conocidas pero la explotación de otras requieren un esfuerzo considerable, para su desarrollo y/o personalización.
6.2. Prevalencia, detectabilidad
6.2.1. El desarrollo basado fuertemente en componentes de terceros, puede llevar a que los desarrolladores no entiendan qué componentes se utilizan en la aplicación o API y, mucho menos, mantenerlos actualizados.
6.3. Técnico, ¿negocio?
6.3.1. Dependiendo del activo que se está protegiendo, este riesgo puede ser incluso el principal de la lista.
6.4. ¿La aplicación es vulnerable?
6.4.1. Es potencialmente vulnerable si: • No conoce las versiones de todos los componentes que utiliza (tanto del lado del cliente como del servidor).El software es vulnerable, no posee soporte o se encuentra desactualizado..No se analizan los componentes periódicamente ni se realiza seguimiento de los boletines de seguridad de los componentes utilizados.
6.4.1.1. Cómo se previene Remover dependencias, funcionalidades, componentes, archivos y documentación innecesaria y no utilizada. Utilizar una herramienta para mantener un inventario de versiones de componentes (por ej. frameworks o bibliotecas) tanto del cliente como del servidor.
7. Metodología y Datos
7.1. Vision
7.1.1. En el Congreso del Proyecto OWASP, participantes activos y miembros de la comunidad decidieron tener una visión de futuro, enfocados en dos tipos de vulnerabilidades, con un orden definido parcialmente por datos cuantitativos y encuestas cualitativas.
7.2. Encuesta a la Industria
7.2.1. Para la encuesta, recopilamos las categorías de vulnerabilidades que estaban identificadas previamente como “en la cúspide” o que se mencionaban en la lista de correo de OWASP Top 10 2017 RC1.
8. Notas sobres los riesgos
8.1. Sobre los riesgos que conllevan las vulnerabilidades La Metodología de Evaluación del Riesgo para el Top 10 está basada en la Metodología de Evaluación de Riesgo de OWASP. Para cada categoría del Top 10, estimamos el riesgo típico que representa cada vulnerabilidad en una aplicación web, al observar los factores de probabilidad comunes y los factores de impacto para esa vulnerabilidad. Luego, ordenamos el Top 10 de acuerdo a todas aquellas vulnerabilidades que típicamente presentan el riesgo más significativo para una aplicación. Estos factores son actualizados con cada edición del Top 10 a medida que cambian y evolucionan.
9. Pérdida de Autenticación
9.1. Los atacantes tienen acceso a millones de combinaciones de pares de usuario y contraseña conocidas (debido a fugas de información), además de cuentas administrativas por defecto.
9.2. Los errores de pérdida de autenticación son comunes debido al diseño y la implementación de la mayoría de los controles de acceso.
9.3. ¿La aplicación es vulnerable?
9.3.1. La confirmación de la identidad y la gestión de sesiones del usuario son fundamentales para protegerse contra ataques relacionados con la autenticación.
9.3.1.1. Cómo se previene
9.3.1.1.1. Implemente autenticación multi-factor para evitar ataques automatizados, de fuerza bruta o reúso de credenciales robadas. No utilice credenciales por defecto en su software, particularmente en el caso de administradores.
10. Entidades Externas XML (XXE)
10.1. App. Específica, Explotabilidad
10.1.1. Los atacantes pueden explotar procesadores XML vulnerables si cargan o incluyen contenido hostil en un documento XML
10.2. Prevalencia, detectabilidad
10.2.1. Las herramientas SAST pueden descubrir estos problemas inspeccionando las dependencias y la configuración.
10.3. Técnico, ¿negocio?
10.3.1. Estos defectos se pueden utilizar para extraer datos, ejecutar una solicitud remota desde el servidor. El impacto al negocio depende de las necesidades de la aplicación y de los datos.
10.4. ¿La aplicación es vulnerable? Las aplicaciones y en particular servicios web basados en XML, o integraciones que utilicen XML, pueden ser vulnerables a este ataque.
10.4.1. Cómo se previene
10.4.1.1. De ser posible, utilice formatos de datos menos complejos como JSON y evite la serialización de datos confidenciales. Actualice los procesadores y bibliotecas XML que utilice la aplicación o el sistema subyacente.
11. Configuración de Seguridad Incorrecta
11.1. App. Específica, Explotabilidad
11.1.1. Los atacantes a menudo intentarán explotar vulnerabilidades sin parchear o acceder a cuentas por defecto, páginas no utilizadas, archivos y directorios desprotegidos
11.2. Prevalencia, detectabilidad
11.2.1. Configuraciones incorrectas de seguridad pueden ocurrir en cualquier nivel del stack tecnológico, incluidos los servicios de red, la plataforma, el servidor web
11.3. Técnico, ¿negocio?
11.3.1. Los defectos frecuentemente dan a los atacantes acceso no autorizado a algunos datos o funciones del sistema.
11.4. ¿La aplicación es vulnerable? Falta hardening adecuado en cualquier parte del stack tecnológico, o permisos mal configurados en los servicios de la nube. • Se encuentran instaladas o habilitadas características innecesarias (ej. puertos, servicios, páginas, cuentas o permisos). • Las cuentas predeterminadas y sus contraseñas siguen activas y sin cambios.
11.4.1. Cómo se previene
11.4.1.1. Proceso de fortalecimiento reproducible que agilice y facilite la implementación de otro entorno asegurado Use una plataforma minimalista sin funcionalidades innecesarias, componentes, documentación o ejemplos.
12. Deserialización Insegura
12.1. App. Específica, Explotabilidad
12.1.1. Lograr la explotación de deserialización es difícil, ya que los exploits distribuidos raramente funcionan sin cambios o ajustes en su código fuente.
12.2. Prevalencia, detectabilidad
12.2.1. Este ítem se incluye en el Top 10 basado en una encuesta a la industria y no en datos cuantificables.
12.3. Técnico, ¿negocio?
12.3.1. No se debe desvalorizar el impacto de los errores de deserialización. Pueden llevar a la ejecución remota de código, uno de los ataques más serios posibles.
12.4. ¿La aplicación es vulnerable? Aplicaciones y APIs serán vulnerables si deserializan objetos hostiles o manipulados por un atacante.Comunicación remota e Inter-Procesos (RPC/IPC) • Protocolo de comunicaciones, Web Services y Brokers de mensajes. • Caching y Persistencia • Bases de datos, servidores de caché y sistemas de archivos
12.4.1. Cómo se previene El único patrón de arquitectura seguro es no aceptar objetos serializados de fuentes no confiables o utilizar medios de serialización que sólo permitan tipos de datos primitivos.
13. Registro y Monitoreo Insuficientes
13.1. App. Específica, Explotabilidad
13.1.1. El registro y monitoreo insuficientes es la base de casi todos los grandes y mayores incidentes de seguridad.
13.2. Prevalencia, detectabilidad
13.2.1. Una estrategia para determinar si usted no posee suficiente monitoreo es examinar los registros después de las pruebas de penetración.
13.3. Técnico, ¿negocio?
13.3.1. Permitir que el sondeo de vulnerabilidades continúe puede aumentar la probabilidad de una explotación exitosa.
13.4. ¿La aplicación es vulnerable? El registro y monitoreo insuficientes ocurren en cualquier momento: • Eventos auditables, tales como los inicios de sesión, fallos en el inicio de sesión, y transacciones de alto valor no son registrados. • Advertencias y errores generan registros poco claros, inadecuados o ninguno en absoluto. • Registros en aplicaciones o APIs no son monitoreados para detectar actividades sospechosas. • Los registros son almacenados únicamente de forma local.
13.4.1. Cómo se previene
13.4.1.1. Asegúrese de que todos los errores de inicio de sesión, de control de acceso y de validación de entradas de datos del lado del servidor se pueden registrar para identificar cuentas sospechosas. Asegúrese de que las transacciones de alto impacto tengan una pista de auditoría con controles de integridad para prevenir alteraciones o eliminaciones. Asegúrese que todas las transacciones de alto valor poseen una traza de auditoría con controles de integridad que permitan detectar su modificación o borrado, tales como una base
14. Proximos pasos para desarrolladores
14.1. Establezca y utilice procesos de seguridad repetibles y controles estándar de seguridad
14.2. Requisitos de Seguridad en Aplicaciones
14.2.1. Arquitectura de seguridad en aplicaciones
14.2.1.1. Controles de Seguridad Estándar
14.2.1.1.1. Educación de la Seguridad en Aplicaciones
15. Proximos pasos para testers
15.1. Comprender el Modelo de Amenazas
15.2. Comprender su SDLC
15.3. Estrategias de pruebas
15.4. Lograr cobertura y precisión
16. Proximos pasos para las organizaciones
16.1. Inicio
16.1.1. Enfoque basado en el catálogo de riesgos
16.1.1.1. Contar con una base sólida
16.1.1.1.1. Integrar la Seguridad en los procesos existentes