A1:2017-Injection. (Inyección de código) 

Los ataques de inyección se producen cuando un atacante consigue enviar datos no confiables a un intérprete como parte de un comando o consulta a BBDD.
Estos datos maliciosos pueden hacer que el intérprete ejecute comandos no consultas no deseadas, e incluso que pueda acceder a datos sin autorización. 

Estos ataques pueden mitigarse filtrando las peticiones mediante expresiones regulares que capturen patrones concretos en todos los elementos que puedan introducir código en el servidor (cookies, cabeceras, parámetros, cuerpos de peticiones, etc).

También es recomendable el uso de APIs seguras que no utilicen el intérprete al completo, o bien provean una interfaz parametrizada que permita separar los datos de las consultas.

A2:2017-Broken Authentication. (Autenticación rota) 

Las funciones de la aplicación relacionadas con la autenticación y la administración de sesiones a menudo se implementan de manera incorrecta, lo que permite a los atacantes comprometer contraseñas, claves o tokens de sesión, o aprovechar otros fallos de implementación para asumir las identidades de otros usuarios de forma temporal o permanente. 

Algunos de los API managers más utilizados del mercado proveen funcionalidad que evita este tipo de ataques mediante servidores dedicados de autenticación, seguridad OAuth, JWT y otros mecanismos. 

Sin embargo también deben cuidarse otros aspectos para evitar ataques relacionados con el robo de credenciales:

• Implementar autenticación multi factor siempre que sea posible

• No usar credenciales por defecto en despliegues de productos comerciales.

• Establecer una política de fortaleza de contraseñas y realizar chequeos periódicos de la fortaleza de contraseñas cambiadas recientemente

• Limitar o retardar incrementalmente el número de reintentos de autenticación. Registrar todos los accesos y establecer sistemas de alerta para detectar ataques de fuerza bruta, robo de credenciales, etc.

A3:2017-Sensitive Data Exposure. (Exposición de datos sensibles)

Muchas aplicaciones web y APIs no protegen adecuadamente los datos confidenciales, como los financieros y de salud. Los atacantes pueden robar o modificar esos datos débilmente protegidos para cometer fraude con tarjetas de crédito, robo de identidad u otros delitos. Los datos confidenciales pueden verse comprometidos sin protección adicional, como el cifrado en almacenamiento o en tránsito, y requieren precauciones especiales cuando se intercambian con el navegador.

A4:2017-XML External Entities (XXE). (Entidades XML externas)

Muchos procesadores XML más antiguos o mal configurados evalúan las referencias de entidades externas dentro de los documentos XML. Las entidades externas permiten que se pueda acceder al contenido interno de la máquina en la que corre la aplicación mediante el controlador de URI de archivos. Esto permite acceder y exponer externamente recursos compartidos de archivos internos, puertos internos, ips internas, etc, así como la ejecución remota de código y ataques de denegación de servicio.

La mejor forma de mitigar estos ataques es determinar de forma precisa el contenido que admite la aplicación en el cuerpo de las peticiones, de forma que si no se usa XML no se permita enviar dicho contenido. Si, por el contrario, se permite el envío de XML es mejor deshabilitar los DTDs y evaluar el contenido de las peticiones siempre.

A5:2017-Broken Access Control. (Control de acceso roto)

Las restricciones sobre lo que pueden hacer los usuarios autenticados a menudo no se aplican correctamente. Los atacantes pueden aprovechar estos fallos para acceder a funciones y / o datos no autorizados, como acceder a las cuentas de otros usuarios, ver archivos confidenciales, modificar los datos de otros usuarios, cambiar los permisos de acceso, etc.

Es necesario contar con un mecanismo de control de acceso que puede implementarse de distintas formas. Puede aplicarse a nivel de usuario o aplicación, tanto por endpoint como a nivel de API o aplicación completa. Puede hacerse uso de scopes OAuth o mecanismos de grano más fino como XACML.

A6:2017-Security Misconfiguration. (Configuración de seguridad errónea)

La configuración incorrecta de seguridad es el problema más común. Esto suele ser el resultado de configuraciones predeterminadas inseguras, configuraciones incompletas o ad hoc, almacenamiento en la nube abierta, cabeceras HTTP mal configuradas y mensajes de error detallados que contienen información confidencial. No solo todos los sistemas operativos, frameworks, bibliotecas y aplicaciones deben configurarse de forma segura, sino que también deben actualizarse de manera regular e inmediata cuando se liberen parches de seguridad.

Otras prácticas recomendables son: 

• Usar la funcionalidad mínima e imprescindible para el funcionamiento del sistema

• Configurar todos los entornos por igual usando distintas credenciales en cada uno, así como un procedimiento automatizado para el despliegue de los mismos.

• Asegurar una arquitectura segmentada en la que cada componente esté separado de los demás para evitar comprometer su seguridad en caso de sufrir un ataque.

A7:2017-Cross-Site Scripting XSS. (Ataques de scripting entre dominios)

Los ataques de XSS ocurren cuando una aplicación incluye datos que no son de confianza en una página web sin la validación o el escape adecuados, o actualiza una página web existente con datos proporcionados por el usuario mediante una API de navegador que puede crear HTML o JavaScript. Cross Site Scripting permite a los atacantes ejecutar scripts en el navegador de la víctima que pueden secuestrar sesiones de usuarios, desfigurar sitios web o redirigir al usuario a sitios maliciosos.

La mitigación de este tipo de ataques pasa por usar frameworks seguros, como React JS, en la aplicación frontal. También es posible codificar los datos de peticiones HTTP no fiables en la salida HTML. No obstante, la protección más eficaz es aplicar una política de seguridad de contenidos que impida colocar scripts en el navegador del cliente, asumiendo que no hay otras vulnerabilidades en los contenidos procedentes de fuentes externas como CDNs.

A8:2017-Insecure Deserialization (Deserialización insegura)

La deserialización insegura a menudo conduce a la ejecución remota de código. Incluso si los fallos de deserialización no dan como resultado la ejecución remota de código, se pueden usar para realizar ataques, incluidos ataques de reproducción, ataques de inyección y ataques de escalada de privilegios.

Estos ataques aprovechan la funcionalidad adicional ofrecida por la deserialización nativa de muchos lenguajes de programación usándola de forma maliciosa. La forma más segura de mitigarlos es no aceptar objetos serializados de fuentes no fiables o permitir sólo objetos con tipos de datos primitivos. No obstante, esto no es siempre posible. En ese caso pueden aplicarse otras técnicas, algunas de las cuales dependen del lenguaje en el que esté implementada la aplicación.

A9:2017-Using Components with Known Vulnerabilities.

Los componentes, como bibliotecas, frameworks y otros módulos de software, se ejecutan con los mismos privilegios que la aplicación. Si se explota un componente vulnerable, dicho ataque puede facilitar la pérdida de datos o la toma de control del servidor. Las aplicaciones y APIs que utilizan componentes con vulnerabilidades conocidas pueden ver comprometida su seguridad y permitir varios ataques.

Es muy importante mantener actualizados e instalar los parches de seguridad de todos los componentes implicados en el sistema: aplicación cliente, API Managers, servidores de identidad, proxies y balanceadores de carga, aplicación backend, etc.

Esto debería ser un proceso regular acorde a una metodología de trabajo que incluyese:

• Retirada de dependencias y archivos obsoletos, funcionalidad innecesaria, etc.

• Inventariado continuo de las versiones de los componentes a lo largo de todo el sistema. La suscripción a las alertas de seguridad de cada componente es estrictamente necesaria para llevar a cabo este proceso adecuadamente.

• Obtención de componentes desde fuentes oficiales y confiables. Elegir siempre archivos firmados que puedan verificarse para minimizar el riesgo de manipulación de componentes.

• Monitorizar componentes obsoletos o sin mantenimiento para buscar alternativas.

A10:2017-Insufficient Logging & Monitoring.

El registro y la supervisión insuficientes, junto con la falta de integración o la integración ineficaz con la respuesta a incidentes, permiten a los atacantes atacar aún más los sistemas, mantener la persistencia, extender los ataques a más sistemas y manipular, extraer o destruir datos. La mayoría de los estudios muestran que el tiempo para detectar un ataque es de más de 200 días. Además, los ataques suelen ser detectados por terceras partes en lugar de por procesos internos o monitorización.

Las respuestas de las aplicaciones o APIs hacia el consumidor cuando se produce un error no deben ofrecer más información de la estrictamente necesaria, pero internamente se debe detallar el error lo máximo posible (logging). De esa forma, si se programan auditorías periódicas de seguridad o se dispone de un sistema de alertas (monitoring) pueden detectarse ataques de forma temprana o, al menos, periódica.

Es altamente recomendable usar plataformas de logging centralizadas y sistemas de monitorización y alerta.