API REST desde 0 - API3:2023 Broken Object Property Level Authorization

5 min readJul 25, 2023

3,2,1 … Empezamos!

Nueva entrada en el blog continuando la entrada anterior, dónde se explicaba la vulnerabilidad API2:2023 - Broken Authentication.

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

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

¡Espero que os resulte útil!

API3:2023 — Broken Object Property Level Authorization

Descripción

Broken Object Property Level Authorization, también conocido como BOPLA (Autorización incorrecta a nivel de propiedad de objeto, en castellano) es nuevo en el TOP 10 debido a que combina el punto API3:2019 - Excessive Data Exposure y el API6:2019 - Mass Assignment, centrándose en la causa raíz: la falta o la validación incorrecta de la autorización a nivel de propiedad del objeto. Esto conlleva a la exposición excesiva de la información que devuelve la API tras realizar una petición o manipulación de información por parte de terceros no autorizados.

Con respecto a Excessive Data Exposure o Exposición excesiva de datos, las APIs pueden exponer muchos más datos de los que el usuario necesita legítimamente, confiando en que el cliente haga el filtrado. En el caso de que un atacante realice una petición directamente a la API, en la respuesta de la petición se mostrará toda la información, en algunos casos, más de la necesaria.

Con respecto a Mass Assignment o Asignación masiva, la API toma los datos que el usuario proporciona en la petición y los guarda sin filtrar correctamente los atributos de la lista blanca, en el caso de que esta esté configurada para la sanitización de estos. Los atacantes pueden tratar de adivinar las propiedades de los objetos realizando diversas peticiones o proporcionar propiedades adicionales de los objetos en sus solicitudes. De esta forma, pueden detectar configuraciones incorrectas de seguridad y modificar las propiedades de los objetos datos almacenados en el backend, aunque, en teoría, no se debería poder modificar estas propiedades.

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

En este primer caso, el contexto se centra en una aplicación móvil de citas. Bob quiere saber más información del perfil de Alice. La aplicación realiza la petición GET sobre el endpoint de la API /user/profile/001, este le devuelve un 200 OK y le enseña a Bob la información de Alice: nombre completo, género, edad y foto.

En el caso en el que Bob intercepte la petición, podría comprobar que la API devuelve más información del perfil como son la ciudad, teléfono y correo.

API3:2023 - Broken Object Property Level Authorization

Una correcta implementación de la API de la aplicación devolvería la información que se le solicita aunque tenga toda la información almacenada sobre el perfil solicitado, evitando la exposición de datos.

En este caso, solamente devolvería el nombre completo, género, edad y foto, tal y como se puede observar en la siguiente imagen.

En el segundo caso, se puede ver el ejemplo de una API mal configurada que devuelve más información de la necesaria.

Se puede observar en la siguiente imagen como Bob crea un nuevo usuario a través de una petición POST /user/new indicando el username y la pass del usuario. La API gestiona la petición y devuelve un 200 OK.

Una vez creado el usuario, Bob realiza una petición GET sobre el endpoint /user/jack para obtener información sobre el nuevo usuario creado y la API devuelve en la respuesta de la petición el username y el role del usuario creado. Se observa el tipo de usuario creado que es con un rol de user.

Analizando la respuesta de la petición anteriormente realizada, Bob realiza una nueva petición POST /user/new indicando el username, la pass del usuario y el role del usuario con un valor de admin.

La API devuelve un 200 OK indicando que el nuevo usuario creado tiene permisos de admin. De esta forma, se ha podido realizar una escalada de privilegios sobre el usuario jack.

En resumen:

Excessive Data Exposure o Exposición excesiva de datos –> El endpoint de la API expone propiedades de un objeto que se consideran sensibles y no deben ser leídas por el usuario.
Mass Assignment o Asignación masiva –> El endpoint de la API permite a un usuario cambiar, añadir y/o eliminar el valor de una propiedad de un objeto a la que el usuario no debería poder acceder.

Impacto

Las APIs tienden a devolver más información de la necesaria en las respuestas de las peticiones, aunque, en algunas ocasiones, no se observa en el navegador (en el caso de ser una web), si se analiza con detenimiento la petición, podrá verse. Este hecho puede ser aprovechado por un atacante para obtener acceso a datos potencialmente sensibles que pueden incluir información como números de cuenta, direcciones de correo electrónico, números de teléfono, tokens de acceso y más datos personales.

En el caso en el que un atacante explotase esta vulnerabilidad también podría modificar las propiedades de objetos a las que no debería tener acceso como pueda ser el rol en una aplicación, lo que le permitiría escalar privilegios, manipular datos y/o eludir mecanismos de seguridad.

Recomendaciones

Comprobar que, cuando se expone el endpoint de la API, el usuario debe tener acceso a las propiedades del objeto que expone.
Evitar utilizar métodos genéricos como to_json() y to_string(). En su lugar, seleccione las propiedades específicas del objeto que desea devolver.
Si es posible, evitar el uso de funciones que vinculen automáticamente la entrada de un cliente a variables de código, objetos internos o propiedades del objeto (“Asignación masiva”).
Permitir cambios sólo en las propiedades del objeto que deben ser actualizadas por el cliente.
Implementar un mecanismo de validación de respuestas basado en esquemas como capa adicional de seguridad. Como parte de este mecanismo, definir y aplicar los datos devueltos por todos los métodos de la API.
Mantener las estructuras de datos devueltas al mínimo, de acuerdo con los requisitos empresariales/funcionales del punto final.
Validar los datos siempre en el lado del servidor.
Poner en whitelist sólo las propiedades que deben ser actualizadas por el cliente y añadir a una blacklist las propiedades a las que no deben acceder el cliente.

Referencias

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! 😊