¿Qué es la BOPLA?

La autorización a nivel de propiedad de objeto comprometida (BOPLA) es una vulnerabilidad de seguridad en las interfaces de programación de aplicaciones (API) que, a causa de comprobaciones de autorización inadecuadas, permite a los hackers ver o manipular las propiedades de objetos confidenciales. Esto puede provocar la pérdida de datos, la exposición de datos confidenciales, la derivación de privilegios o el robo de cuentas. La BOPLA aparece en el tercer puesto de la lista de los 10 principales problemas de seguridad de las API según OWASP de 2023.

Las aplicaciones web recuperan datos y rellenan campos en las páginas front-end consultando a las API información sobre objetos como registros de bases de datos o archivos. Cada objeto suele contener varios puntos de datos o "propiedades". Por ejemplo, el perfil asociado a una cuenta de usuario puede incluir propiedades como first_name, last_name, email_address, password, SSN_number e is_admin, lo que indica si el usuario tiene privilegios administrativos.

Durante una llamada de API, las API suelen enviar más información de la que técnicamente se requiere en la respuesta de API, dejando a la aplicación cliente que extraiga los datos que necesita y muestre una vista para el usuario. Esta vulnerabilidad crea riesgos en un terminal de API de dos formas diferentes:

Exposición excesiva de datos. Se produce cuando una respuesta de API incluye más información que la llamada de API solicitada y, posiblemente, incluye información confidencial (password y SSN_number en este ejemplo) a la que un usuario o aplicación no debería tener acceso. Cuando se trata de respuestas de API que se muestran en un sitio web o una aplicación, algunos de los datos excesivos solo se encuentran en la propia respuesta de API y se pueden extraer fácilmente. 

Asignación masiva. Se produce cuando un terminal de API permite a un usuario no autorizado cambiar, añadir o eliminar el valor de la propiedad de un objeto. En el registro de ejemplo anterior, cuando la respuesta de API revela innecesariamente que existe una propiedad is_admin, los atacantes podrían derivar privilegios de forma no autorizada cambiando la propiedad is_admin a TRUE. Esto también puede permitirles realizar cambios en otras propiedades o acceder a otros objetos a los que no deberían poder acceder.

La BOPLA se introdujo por primera vez en los 10 principales problemas de seguridad de las API según OWASP de 2023, combinando estas dos amenazas anteriores de exposición excesiva de datos y asignación masiva que aparecían por separado en listas anteriores.

La BOPLA está relacionado con la autorización a nivel de objeto comprometida (BOLA), que aparece en el primer puesto de la lista de los 10 principales riesgos de seguridad de las API según OWASP. Sin embargo, BOLA se refiere a la autorización para acceder a un objeto completo, mientras que BOPLA se refiere a vulnerabilidades que afectan a propiedades individuales dentro de un objeto.

La diferencia entre la autorización a nivel de objeto comprometida (BOLA) y BOPLA es que BOLA hace referencia a un objeto completo, mientras que BOPLA se refiere a una propiedad dentro de un objeto. 

Aunque una API aplique una autorización a nivel de objeto suficiente para evitar ataques de BOLA, estas medidas podrían no ser suficientes para proteger contra ataques de BOPLA. Para mitigar la vulnerabilidad de BOPLA, los equipos deben adoptar autorizaciones más específicas que cubran los objetos, así como sus características, y también deben tener en cuenta los diferentes niveles de acceso dentro de los objetos de API, que a menudo tienen propiedades tanto públicas como privadas.

Los ataques que se centran en la vulnerabilidad de BOPLA pueden permitir a los atacantes:

• Alterar las propiedades de objetos a los que no deberían tener acceso
• Ver datos confidenciales a los que deberían tener prohibido el acceso
• Derivar privilegios para hacerse con el control de cuentas

Tradicionalmente, los equipos de seguridad han confiado en firewalls de aplicaciones web y puertas de enlace de API para defender las API de las amenazas. Sin embargo, los WAF y la seguridad de puerta de enlace de API no tienen en cuenta la lógica empresarial y el contexto de las API, lo que hace imposible detectar los datos confidenciales que se envían a través de una API o entender el nivel de exposición que representan los activos de datos individuales. Estas soluciones de protección de API tampoco pueden distinguir siempre entre llamadas legítimas y actividades maliciosas; por ejemplo, una llamada de API maliciosa que envía una solicitud mediante el método PUT con parámetros adicionales aparecerá como una llamada de API normal a un WAF o una puerta de enlace de API.

Para detectar las vulnerabilidades de BOPLA, los equipos de seguridad necesitan tecnología que pueda identificar una amplia gama de tipos de datos confidenciales que se pueden incluir en las solicitudes y respuestas de API e informar sobre ellos. Las soluciones superiores también deben llevar un seguimiento de la actividad anómala en la que los atacantes manipulen solicitudes de API con parámetros no autorizados. La capacidad de establecer un nivel de referencia y llevar un seguimiento del acceso a las API para cada terminal y usuario puede ayudar a identificar el consumo excesivo y detectar instancias en las que los parámetros adicionales en las llamadas de API no se ajustan al comportamiento normal. La seguridad de las API también debe poder detectar a los atacantes que están sondeando las API durante la fase de investigación de un ataque cuando tratan de entender la estructura y la lógica empresarial de una API.

Asegurarse de que el código es seguro y de que no hay problemas con el permiso de propiedades de objetos debe tener una prioridad elevada para los desarrolladores. Sin embargo, las vulnerabilidades de BOPLA se producen cada vez más en API de terceros sobre las que los equipos de seguridad no tienen ningún control.

Para evitar los ataques de BOPLA, los equipos de seguridad pueden tomar varias medidas esenciales.

Formar a los desarrolladores sobre código seguro. Los equipos de seguridad deben ayudar a los desarrolladores a entender la necesidad de asignar correctamente permisos a nivel de propiedad al tiempo que aplican una estrategia de autorización estandarizada para todos los terminales de API. El código seguro debe tener en cuenta el nivel de autorización de usuario y los requisitos de autorización de todos los recursos de referencia. Las políticas de seguridad deben controlar rigurosamente qué campos se pueden editar a través de listas de permitidos. Los desarrolladores también deben ser conservadores en cuanto a la cantidad y los tipos de datos devueltos en las respuestas de API, y solo deben incluir los datos necesarios para casos de uso que se entiendan bien.

Zero Trust. La implementación del principio de privilegios mínimos, un elemento fundamental de un enfoque Zero Trust para la seguridad, restringe el nivel de acceso de los usuarios al mínimo que necesitan, lo que ayuda a evitar ataques de BOPLA o a limitar los daños que pueden causar.

Detección. Al identificar los terminales de API vulnerables, los equipos pueden alertar a los desarrolladores de problemas e informar a los proveedores cuando sus API son vulnerables.

Supervisión. Una herramienta de seguridad de API puede supervisar el tráfico en busca de ataques, incluida la asignación masiva, que explotan la vulnerabilidad de BOPLA.

Autorización sólida. Al exponer un objeto de una terminal de API, los procesos de autorización deben garantizar que el usuario tenga realmente acceso a las propiedades del objeto. La adopción del control de acceso basado en funciones (RBAC) garantiza que solo las personas autorizadas puedan acceder a propiedades específicas.

Auditorías y actualizaciones. La comprobación y actualización continuas de los permisos ayuda a garantizar que se mantengan actualizados y precisos.