Las últimas dos décadas han visto una proliferación de software (según GitHub, solo en 2020 ha habido un aumento del 35% en los repositorios de código) en todos los aspectos de nuestras vidas en forma de aplicaciones web o móviles. Los adversarios han atacado cada vez más estas aplicaciones y los defensores han adoptado diversas herramientas y tecnologías de prueba para protegerlas.
Hoy en día, la mayoría de las empresas cuentan con un programa de seguridad de aplicaciones (AppSec) para gestionar la implementación de estas herramientas y gestionar las vulnerabilidades asociadas. La única constante en el mundo del desarrollo de software es el cambio, y nunca más que en los últimos años con la adopción generalizada de tecnologías nativas de la nube (como contenedores, plataformas de orquestación) y la ruptura del monolito a través de la adopción de microservicios.
Desafortunadamente para los equipos de AppSec, este panorama en rápida evolución ha significado que muchas de las herramientas que utilizan no están a la altura de la tarea de proteger sus aplicaciones.
En ninguna parte esto es más evidente que con la seguridad de las interfaces de programas de aplicación (API), que son fundamentales para todas las aplicaciones modernas. Las API presentan un desafío único desde la perspectiva de la seguridad debido a su singularidad desde el punto de vista del ataque, un hecho reconocido por OWASP, quien produjo una lista dedicada de los 10 principales para las vulnerabilidades de seguridad de las API .
Por qué las herramientas de AppSec existentes se comportan mal en las API
SAST no fue diseñado para aplicaciones centradas en API
El caballo de batalla de cualquier programa de AppSec es la prueba de seguridad de aplicaciones estáticas (SAST), que es una evaluación de “caja blanca” de las vulnerabilidades en una aplicación derivada del examen del código fuente y la creación de un modelo del flujo de datos a través de una aplicación para determinar dónde La aplicación puede ser vulnerable a ataques externos mediante, por ejemplo, ataques de inyección.
Las rutas de flujo de datos complejas o los marcos no compatibles reducen la precisión de un análisis SAST, ya que el modelo puede estar incompleto o ser inexacto.
En el caso de las API, esto es significativamente más complejo ya que la mayoría de las herramientas SAST están diseñadas para trabajar con aplicaciones web construidas como, por ejemplo, Java Servlet PHttpRequest.Bodyages o páginas ASP .Net.
En este caso, la herramienta SAST detecta instancias HttpRequest.Body dentro de una base de código, ya que normalmente así es como se construye una página web. Desafortunadamente, las API son significativamente más complejas, ya que se construyen de manera diferente utilizando una gran cantidad de marcos de terceros (como SpringBoot, Flask, etc.), y la detección de los puntos de entrada en la aplicación es más compleja, lo que genera modelos inexactos y tasas más altas de falsos negativos.
DAST carece de contexto de API
La prueba de seguridad de aplicaciones dinámicas (DAST) es una evaluación de “caja negra” de una aplicación en ejecución mediante el ejercicio de los puntos finales de la aplicación de la misma manera que lo haría un usuario, o un atacante. Las herramientas DAST son expertas en “spidering” una aplicación web para determinar la estructura de la página y los campos de entrada y luego atacar estos campos para identificar vulnerabilidades.
Desafortunadamente, para una API, el escáner DAST no puede enumerar los puntos finales de la API, lo que hace que tales ataques sean imposibles. Algunas herramientas DAST (como OWASP ZAP ) pueden ingerir un archivo OpenAPI / Swagger para iniciar el proceso de spidering.
Incluso en este caso, sin una comprensión más profunda de los puntos finales de la API, las herramientas DAST no pueden proporcionar una evaluación inteligente de la seguridad de la API. Por ejemplo, un escáner DAST no podrá identificar problemas de Autorización de nivel de objeto roto ( BOLA ) a menos que tenga conocimiento del valor del parámetro utilizado para identificar el objeto (para identificar este campo) y luego poder interpretar el respuesta para determinar si el ataque tuvo éxito o si se devuelve algún error.
Desplazamiento a la izquierda en seguridad API
Las herramientas de seguridad han mostrado grandes avances en la última década, sin embargo, el impedimento más importante para las iniciativas de AppSec altamente escalables y efectivas es que las actividades de seguridad se llevan a cabo demasiado tarde en el ciclo de vida de desarrollo de software (SDLC).
Probar demasiado tarde aumenta el costo de la remediación y reduce la probabilidad de que el desarrollador repare. En el caso de las aplicaciones monolíticas típicas, no había otra alternativa que probar al final del ciclo, ya que se requería una instancia funcional y en ejecución de la aplicación para realizar las pruebas, particularmente para DAST.
Con el advenimiento de una arquitectura centrada en API basada en microservicios, es posible probar cada una de las API individuales a medida que se desarrollan en lugar de requerir una instancia completa de una aplicación, lo que permite un enfoque de “cambio a la izquierda” que permite la prueba temprana de componentes individuales. .
Debido a que las API se especifican antes en el SDLC y tienen un contrato definido (a través de una especificación OpenAPI / Swagger), son ideales para un enfoque de prueba de seguridad preventivo de “cambio a la izquierda”: la especificación de API y la implementación subyacente se pueden probar en un IDE de desarrollador como una actividad independiente.
El núcleo de este enfoque son las herramientas de prueba específicas de API, ya que se requiere un conocimiento contextual del contrato de API. Las herramientas SAST / DAST existentes serán en gran parte inadecuadas en esta aplicación; en la discusión sobre las pruebas DAST para detectar BOLA identificamos la incapacidad de la herramienta DAST para comprender el comportamiento de la API.
Al especificar el comportamiento de la API con un contrato, se puede aplicar y verificar el comportamiento correcto, lo que permite un modelo de seguridad positivo (el comportamiento deseado está en la lista blanca) en lugar de un enfoque de lista negra como DAST.
El siguiente diagrama resume las diferencias clave entre las pruebas nativas de seguridad de API y las pruebas DAST, de 42Crunch :
Fuente: 42Crunch.
Las herramientas de prueba de seguridad que he discutido generalmente son operadas por los equipos de seguridad o AppSec de una organización y, a menudo, se imponen a los desarrolladores que pueden encontrarlas inadecuadas para las prácticas de desarrollo modernas, como la integración continua (CI) y la implementación continua (CD), lo que a veces lleva al desarrollador frustración y menores tasas de adopción de herramientas de seguridad.
Por el contrario, es más probable que se adopten y utilicen activamente las herramientas de seguridad de API que pueden agregar valor al esfuerzo de desarrollo (por ejemplo, permitiendo la validación continua de las especificaciones de API) dentro de sus entornos.
Conclusión
¿Tienen las herramientas de prueba de seguridad más tradicionales, como SAST y DAST, un lugar en su entorno de desarrollo de API? Es casi seguro que la respuesta es sí, especialmente si tiene una inversión y un proceso centrados en estas herramientas. Al aprovechar la naturaleza declarativa de las especificaciones de API, una organización inteligente puede utilizar herramientas específicas de API para adoptar un enfoque de “cambio a la izquierda” y aplicar y probar la seguridad de API mediante un modelo de seguridad positivo. Todas las API resultantes producidas se garantizan seguras por diseño, lo que proporciona una base sólida para la pila de aplicaciones de alto nivel (páginas web o aplicaciones móviles) que se pueden probar utilizando herramientas SAST / DAST.
Publicado originalmente en The New Stack
Publicado en
Queremos ser su aliado tecnológico
Permítanos conocer sus requerimientos y desarrollar una estrategia de automatización innovadora para su empresa.
Aún no hay comentarios, ¡añada su voz abajo!