API REST desde 0 - API1:2023 Broken Object Level Authorization

Carol12Gory - Oasis
4 min readJul 9, 2023

--

3,2,1 … Empezamos!

Nueva entrada en el blog continuando la entrada anterior, dónde se explicaba qué era una API, los tipos de API que existen según su funcionalidad, una comparativa entre el TOP 10 - API 2019 y el TOP 10 - API 2023 y una breve explicación de la actualización que ha sufrido cada punto.

Se recomienda leer estos artículos antes de continuar con la lectura:

Tanto esta, como la siguientes publicaciones van a tratar en detalle cada vulnerabilidad que compone el TOP 10 - API 2023.

¡Espero que os resulte útil!

API1:2023 — Broken Object Level Authorization

  • Descripción

Broken Object Level Authorization, también conocido como BOLA (Autorización incorrecta a nivel objeto en castellano) es un mecanismo de control de acceso que suele implementarse a nivel de código para validar que un usuario sólo puede acceder a los objetos sobre los que tiene permiso para acceder.

Antes de continuar, hacer énfasis en la diferencia entre autorización y autenticación, que no es los mismo. La autenticación consiste en proporcionar y validar la identidad (login). La autorización determina a qué funcionalidades y datos puede acceder el usuario una vez autenticado en el sistema. A través de la autorización se conceden o deniegan las solicitudes de acceso a un determinado recurso.

Como la mejor forma de entender las cosas es con ejemplos, vamos a ver esta vulnerabilidad con diferentes situación que se pueden dar.

Para que el ataque Broken Object Level Authorization o BOLA pueda realizarse, los atacantes sustituyen el ID (elemento identificativo y único) de su propio recurso en la llamada a la API por el ID de un recurso perteneciente a otro usuario. La falta o ausencia de comprobaciones de autorización sobre los objetos permite a los atacantes acceder al recurso especificado. Este ataque también se conoce como IDOR (Insecure Direct Object Reference), también presente en aplicativos Web.

En la siguiente imagen vemos como Bob, ya logueado en la aplicación, realiza peticiones a la API para que ésta le devuelva diferentes recursos. Al pertenecer a Bob tanto el objeto 100 como el 101, la API funciona correctamente y le hace entrega de dichos objetos.

En el tercer caso que se observa en la imagen, la API está mal implementada y permite a Bob acceder a los recursos que pertenecen a Alice, en este caso al objeto 102.

Esto da lugar a la vulnerabilidad IDOR (Insecure Direct Object Reference), es decir, en este caso Bob tendría acceso a todos los recursos aunque no tuviera autorización para acceder a ellos.

01 - API1:2023 - Broken Object Level Authorization

A continuación, vemos la forma correcta para evitar esta vulnerabilidad.

Bob realiza las peticiones de acceso a los objetos 100 y 101 y ambos son devueltos por la API. En el caso del objeto 102, el cual pertenece a Alice, la API le devuelve un error 403 Forbidden ya que está intentando acceder a un recurso que no le pertenece ni tiene autorización para acceder.

02 - API1:2023 - Broken Object Level Authorization

Para una correcta implementación de la autorización sobre los diferentes objetos, se tenga o no acceso, lo que se recomienda es que se generen GUIDs (Globally Unique Identifier o identificador único global) con valores aleatorios e impredecibles sobre los diferentes objetos.

Como se explicó en el post anterior, con el recurso de hypermedia, internamente se sabe la relación entre el GUID y el objeto, dificultando a un atacante el descubrimiento de posibles objetos tanto suyos como de otros usuarios, en el caso de que no esté bien configurada la parte de la autorización.

03 - API1:2023 - Broken Object Level Authorization
  • Impacto

En el caso en el que un atacante pueda acceder a recursos u objetos sobre los que no tiene autorización, podría dar lugar a una filtración de información sensible a usuarios sin autorización, la pérdida de estos o su manipulación. Esta vulnerabilidad podría suponer la perdida del control total de la cuenta.

  • Recomendaciones

Utilizar un mecanismo de autorización para comprobar si el usuario conectado tiene acceso para realizar la acción solicitada en el registro.

Utilizar valores aleatorios e impredecibles como GUIDs para los IDs de los objetos.

  • Referencias

- https://owasp.org/API-Security/editions/2023/en/0x00-header/

- https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/

En los próximos posts se continuará explicando cada uno de los puntos que quedan por detallar del TOP 10 - API 2023.

¡Nos vemos en el próximo! 😊

--

--

Carol12Gory - Oasis

Offensive Security Engineer en Telefónica Tech. Co-autora del libro Social Hunters: Hacking con ingeniería social en el Red Team. carol12gory.com | @Carol12Gory