Guía de OWASP para APIs 2023

Como desarrolladores y/o responsables de la seguridad de una, aplicación, debemos poder definir el límite de lo correcto y lo incorrecto a la hora de construir y diseñar la arquitectura de la misma, muchas veces pasa que en el proceso nos olvidamos de tener en cuenta los errores más comunes cometidos por otros desarrolladores o nos olvidamos los principales intereses de los atacantes. Si tuviéramos que mantenernos al día por nuestra cuenta, sería una tarea titánica ya que las vulnerabilidades y los intereses de los atacantes en buscar nuevos horizontes, tienen una tasa exponencial de variación.

Entonces producto de esto nos surgen varias preguntas, a la hora de proponer un diseño seguro ya sea de una aplicación web, servicio web y/o aplicación móvil; ¿Cómo mantenernos al día? ¿Cómo enfrentar esa ola de novedades sin olvidarnos lo más importante? Uno podría fácilmente decir, que lo más conveniente sería armar una lista de vulnerabilidades más conocidas en base a la experiencia personal, pero allí solo estaríamos teniendo en cuenta una sola óptica de la situación, si bien es deseable que las empresas tengan un histórico de vulnerabilidades o fallas anteriores para poder aplicarlos a la mejora continua, también es cierto que ese histórico va a estar basado en un solo tipo de arquitectura y/o en un solo tipo de aplicación. Esto en el corto plazo quizás no tiene impacto a nivel empresa, pero si la misma está constantemente inmersa en procesos de innovación como debería ser, se encontrará siempre en el dilema de cambiar la arquitectura constantemente y proponer mejoras a los procesos habituales desarrollados en el día a día, llevándola a implementar nuevas funcionalidades y nuevas tecnologías que podrían estar en riesgo bajo la perspectiva de ese histórico (Hecho en función a una arquitectura obsoleta).

Ahí es donde debemos barajar y dar de nuevo repartiendo las cartas en un orden alternativo que nos va a proveer nuevos puntos de vista. Porque invertir esfuerzos en sacar estadísticas y armar históricos si puede haber alguien que haya hecho antes lo mismo pero no solo referido a una arquitectura particular, sino que también a muchas situaciones ocurridas aplicadas a distintos ámbitos.

Ese caso del cual les menciono es el caso de OWASP, (Open Worldwide Application Security Project). Un proyecto que surge de la necesidad de relevar los intereses más comunes de los atacantes en función a los errores que los desarrolladores comentan a lo largo del ciclo de desarrollo de software, la comunidad OWASP está formada por empresas, organizaciones educativas y particulares de todo el mundo. Juntos constituyen una comunidad de seguridad informática que trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser utilizadas gratuitamente. Actualizando las principales tendencias, como consecuencia de las mejoras existentes en los procesos de desarrollo seguro. Esta organización que nació enfocada en errores asociados a aplicaciones web, hoy en día tiene en su haber varias versiones, tipificando las vulnerabilidades más explotadas y agrupándolas acorde a la naturaleza de la aplicación. Tenemos actualmente el OWASP Web, OWASP Mobile, y OWASP API, el cual será detallado en este artículo: OWASP - API 2023

Un elemento fundamental de la innovación en el mundo actual impulsado por las aplicaciones es la interfaz de programación de aplicaciones (API). Desde bancos, comercio minorista, transporte hasta IoT, vehículos autónomos y ciudades inteligentes, las API son una parte fundamental de las aplicaciones móviles, SaaS y web modernas por lo que al encontrarlas habitualmente con frecuencia a nivel cliente están pasando a ser el principal objetivo de los atacantes, ante los descuidos que se cometen a la hora de implementarlas.

Si bien el concepto de una API es sencillo, un servicio que esta brindando un recurso y una interfaz del otro lado consumiendo las distintas prestaciones, tal como se muestra en la imagen;

La mayoría de los desarrolladores omiten el proceso de asegurarlas, quizás por una falsa sensación de seguridad que los lleva a pensar que un atacante ante el desconocimiento del funcionamiento de la misma, no va a tener en la mira estos servicios ya que están fuera de la superficie del ataque. Cuando en realidad ocurre todo lo contrario.

A continuación veremos las 10 vulnerabilidades más frecuentes en este ámbito:

API1 - Broken Object Level Authorization

Object level authorization es un mecanismo de control de acceso, que usualmente está implementado a nivel de código, encargado de validar que un usuario acceda solamente a los objetos que tiene permitido acceder. Suponiendo el caso de que un usuario presenta sus credenciales ante la interfaz alojada en el teléfono y luego él mismo quiere acceder a otro recurso provisto por el servicio, tal como se muestra a continuación:

Si el sistema le devuelve al usuario cualquier objeto sin validar que el mismo tenga permisos para realizar la acción solicitada sobre el objeto solicitado, estamos en presencia de un Broken Object Level Authorization, por lo que un atacante accede sin problemas a cualquier objeto.

API2 - Broken Authentication

Esta falla, común también en las aplicaciones web, se puede manifestar en varias vulnerabilidades debido a que cuando nos enfrentamos a un endpoint de una API, existe un desafío inicial para poder consumir la misma y comenzar a intercambiar recursos.

Existen varios casos en donde esto puede llegar a ocurrir:

• Si la API permite ataques de Credential Stuffing, en donde los atacantes utilizan credenciales conocidas a partir de cuentas y/o nombres de usuarios filtrados en algún reciente leak.
• Si la API permite contraseñas débiles o mecanismos débiles de autenticación como por ejemplo: Basic Authentication.
• Si la API intercambia datos a través de parámetros GET, que permitiría la filtración de datos de autenticación a través de la memoria en reposo alojada en el dispositivo de la víctima.
• Si se utilizan tokens JWT pero los mismos no se validan en toda la transacción.
• Si los tokens utilizados no tienen la correcta caducidad configurada.
• Si el endpoint no posee protección contra ataques de fuerza bruta (Mala implementación o nula implementación de captcha).
• Si se utilizan algoritmos débiles para el cifrado de los datos, en reposo y en tránsito.

Potencial escenario:

• Un atacante invoca el módulo de reiniciar contraseña que concluye en la invocación de un módulo similar a este /api/v1/reset-password.



• Luego automáticamente la API envía una orden de reinicio para el usuario 456, como consecuencia de esto el servicio envía un reset token de 5 dígitos al mailbox del usuario afectado. En la interfaz se le va a pedir que ingrese el token.


• Al ingresar cualquier token, el atacante captura el Request pudiendo leer una petición similar a esta;



• Como nuestro servicio web no cuenta con la debida protección el atacante puede realizar un bruteforce con la herramienta Burp Suite para adivinar el token de 5 dígitos, estando en presencia de un ataque de Broken Authentication.

API3 - Broken Object Property Level Authorization

Esta categoría de vulnerabilidades, combina dos vulnerabilidades descritas en la revisión de 2019 asociada a las API, en donde tenemos Excessive Data Exposure y Mass Assignment, enfocadas básicamente en la manipulación de información sensible y la exposición de este tipo de información, haciendo referencia a las propiedades de los objetos.

Un ejemplo simple de esta vulnerabilidad podría ser el siguiente ;

• El usuario ingresa el número de tarjeta y los datos correspondientes para realizar una compra.
• Luego estos datos son transferidos desde el API gateway a la “API Interna”. (Hasta aquí ningún inconveniente)
• Al recibir estos datos, la API envía una respuesta con muchos más datos de los que debería enviar al usuario.

API4 - Unrestricted Resource Consumption

Algunas consultas requieren recursos como ancho de banda, consumo de CPU, memoria y almacenamiento y otras tienen relegada esta capacidad de procesamiento a los proveedores del servicio, ya que es muy probable que no todas las APIs de una aplicación están bajo el control de la empresa que desarrolla la aplicación. Muchas estructuras utilizan APIs de terceros y pagan por cada request, por lo que estos ataques están asociados a perjudicar los costos de mantenimiento de esas APIs.

Por ejemplo:

• Un módulo de autenticación tiene un formulario de recupero de contraseña
• Este formulario de recupero de contraseña tiene un servicio externo de envío de SMS que incurre en un costo por cada request que se genere al mismo.
• Un atacante encuentra la forma de consumir este servicio gratuitamente utilizando este envío de SMS para otros fines sin la necesidad de presentar credenciales.

API5 - Broken Function Level Authorization

En primer lugar los atacantes buscan un target que contenga dos o más tipos de cuentas. Podría ser un usuario común encargado de las tareas habituales trabajadas sobre su perfil y en otro caso podría ser un usuario administrador, encargado de tener una visión general de toda la aplicación. Capturando varias llamadas a la respectiva API el atacante encuentra un parámetro oculto que hace referencia al tipo de cuenta, por lo que procede a cambiarlo, permitiendo acceder a una función de otro usuario que no corresponde a sus tareas.

En resumen dentro de los manejos de autorizaciones, estas APIs vulnerables no controlan correctamente el acceso a las funciones que corresponden a perfiles más avanzados.

En esta imagen el atacante simplemente reemplaza el módulo users por admin y accede a la información de todos los usuarios.

API6 - Unrestricted Access to sensitive business flows

A la hora de crear un endpoint es muy importante entender cuáles son los flujos de negocio más importantes, por lo general son los que se llevan la mayor cantidad de información crítica de la empresa y de las operaciones por lo que protegerlos se transforma en la principal tarea de todo programador. Si estos flujos quedan expuestos, en el funcionamiento de la aplicación podríamos llegar a tener un impacto de medio a crítico dependiendo del flujo de negocio que haya quedado expuesto a través de estas fallas.

Algunos ejemplos más comunes de flujos de negocio expuestos se dan en las siguientes situaciones:

• Un atacante que tenga la posibilidad de comprar todos los productos de alta demanda ante las debilidades de las aplicaciones, para luego venderlos a un mayor precio.
• Crear SPAM en un sistema que tenga expuesto el flujo de creación de comentarios y/o posts.
• Un flujo de reserva de asientos en un cine que al quedar expuesto le brinda la posibilidad al atacante de reservar todos los lugares.

Como vimos en estos tres casos, las APIs presentan estas vulnerabilidades debido a que no se requiere autenticación para utilizar estos recursos. Por lo que le permite a un usuario saltarse el flujo normal de la aplicación e ir a flujos alternativos que no corresponden a su flujo natural de la misma.

Imagen extraída de https://medium.com/

API7 - Server Side Request Forgery

Esta vulnerabilidad ocurre cuando una API permite hacer consultas HTTP del lado del servidor hacia un dominio arbitrario elegido por el atacante.

Esto le permite a un atacante hacer conexión con servicios de la infraestructura interna donde se aloja la API y filtrar información sensible.

Los casos son variados, pero veamos cómo un atacante podría robar las llaves de AWS de una empresa.

• Supongamos que una petición web que consulta el stock de un producto, se ve de la siguiente manera.
• En este caso, un atacante podría modificar la consulta para, en lugar de pedir datos de stock del producto, pedir los metadatos de la API y encontrar una lista de roles válidos.
• Aunque inicialmente la API tenga restricción de acceso para que no se puedan hacer consultas externas, la consulta se origina desde el servidor. Por esto, la API va a responder a la consulta como si tuviera autorización para hacerla.

API8 - Security Misconfiguration

Al igual que en las aplicaciones web existen en las APIs malas configuraciones de seguridad. Esto ocurre cuando no se aplica el correcto hardening de la plataforma o existen permisos mal configurados a la hora de desplegar las mismas. Dentro de las cuestiones a revisar los desarrolladores suelen omitir la mayoría de cuestiones de seguridad debido a la falta de automatización en la etapa de testing. Dentro de las posibles malas configuraciones encontramos las siguientes:

• Últimos parches actualizados
• Servicios innecesarios habilitados
• Falta de controles y/o directivas respecto de la memoria caché
• Ausencia de políticas respecto del uso de CORS
• Mal manejos de errores

API9 - Improper Inventory Management

Las APIs tienden a exponer más endpoints que las tradicionales aplicaciones web, esto lleva a los desarrolladores a crear la correspondiente documentación del funcionamiento de cada una de las APIs correspondientes. El inventario apropiado debe ser relevado ya que si se pierde la documentación o si se filtra, los atacantes podrían ampliar su superficie de ataque llevando al máximo los conocimientos sobre el manejo de los servicios expuestos.

Esta vulnerabilidad, sumada a la no protección se transforma en la principal bomba de tiempo asociada a estas cuestiones. Siempre debemos preguntarnos, para cada API, si todos los endpoints actuales deberían estar disponibles, para aplicar el principio de mínimos privilegios a toda la configuración de la arquitectura.

En esta imagen vemos la potencial complejidad de documentar el funcionamiento de una arquitectura que va agregando distintas APIs, a medida que se requieren.

En un caso de ejemplo, supongamos que tenemos adicionalmente la siguiente url:

⦁ < http://WEBSITE:5555/api/v2/res//all >

Si prestamos especial atención a la construcción de la url nos damos cuenta que estamos trabajando con la versión 2 de la misma, un atacante que entienda este tipo de funcionamiento podría reemplazar el v2 por un v1, para ver qué módulos quedaron disponibles relacionados con la versión anterior de la API. Muchas veces ocurre que los desarrolladores restringen módulos que no usan en la nueva versión, pero descuidan versiones anteriores que podrían llegar a estar activas como consecuencia de un incorrecto relevamiento a la hora de armar el inventario.

API10- Unsafe Consumption of APIs

Los desarrolladores tienden a recibir datos de APIs de terceros, muchas veces esos consumos que están bajo la órbita de la arquitectura de la empresa no tienen un tratamiento de seguridad adecuado al resto de los flujos de la aplicación que consume estos servicios.

Por lo que la desatención de estos componentes genera una superficie de ataque interesante para la perspectiva del ciberdelincuente ya que puede utilizar estos recursos para perjudicar el funcionamiento de la aplicación.

Tal como se ve en la imagen, si tengo mis API endpoints y son controlados por ejemplo por un API Management de terceros el atacante que encuentre una falla en este componente de terceros va a poder vulnerar toda la arquitectura diseñada previamente. Es por eso que los desarrolladores tienen que estar al tanto constantemente de las fallas que pueden llegar a existir en los sistemas que se contratan y se tercerizan.

Recomendaciones

A la hora de pensar cómo protegernos ante estas cuestiones diría que lo que necesitamos es aumentar nuestra conciencia respecto de los activos informáticos que desplegamos, cuando construimos una aplicación. Es importante seguir las recomendaciones de OWASP respecto de cada punto para poder ejecutar una correcta implementación de las APIs y no abusar del potencial desconocimiento de los atacantes. Los invitamos a recorrer el OWASP API security Project, para más soluciones puntuales en cada caso. Si les gusto este post y desean que hagamos uno relacionado con las recomendaciones déjenlo en los comentarios.

Conclusión

Para tener en cuenta revisando el tema podemos observar que muchos errores se arrastran del manejo descuidado que por lo general tienen las aplicaciones web, el principal error es en primer lugar creer que nadie va a prestar atención a determinado punto de nuestra arquitectura y sumado a eso creer que la seguridad por oscuridad (Uso del diseño secreto como medida de protección, seguridad por desconocimiento) es el mecanismo más efectivo para defendernos cuando en realidad, en muchas ocasiones los atacantes saben más que nosotros de nuestra misma aplicación.