Las 10 mejores API de la serie OWASP de Coders Conquer Security: autorización a nivel de objeto roto

Las amenazas a la ciberseguridad en estos días son omnipresentes e incesantes. La situación ha empeorado tanto que tratar de mantenerse al día con ellos después de implementar los programas se ha vuelto casi imposible. Sin embargo, en esta era de DevSecOps, entrega continua y más datos que nunca, las organizaciones astutas ayudan a sus desarrolladores a convertirse en superestrellas conscientes de la seguridad, que ayudan a eliminar las vulnerabilidades más comunes antes de que lleguen a la producción. Hemos abordado vulnerabilidades web, más el nuestro Las 8 mejores infraestructuras como código errores, y ahora es el momento de familiarizarse con el próximo gran desafío de seguridad del software. ¿Estás preparado?

La próxima serie de blogs se centrará en algunos de los peores errores de seguridad relacionados con las interfaces de programación de aplicaciones (API). Son tan graves que crearon el Open Web Application Security Project (AVISPA) lista de las principales vulnerabilidades de la API. Dada la importancia de las API para las infraestructuras informáticas modernas, se trata de problemas críticos que debe mantener fuera de sus aplicaciones y programas a toda costa.

Un ejemplo perfecto de por qué es esencial usar código para reforzar la seguridad se puede encontrar en un examen de la vulnerabilidad de autorización a nivel de objeto roto. Esto ocurre cuando los programadores no definen de forma explícita qué usuarios pueden ver objetos y datos, ni proporcionan ningún tipo de verificación para ver, cambiar o realizar otras solicitudes para manipular objetos o acceder a ellos, lo que les permite modificar objetos y datos y acceder a ellos a través de los puntos finales de la API. Un punto final de la API es un punto de contacto, a menudo una URL, que se utiliza para la comunicación entre la propia API y otro sistema. La capacidad de conectividad entre las aplicaciones ha hecho que algunos de los programas más apreciados del mundo sean más populares, pero se corre el riesgo de exponer varios puntos finales si no son herméticos.

También puede ocurrir cuando los programadores olvidan o heredan propiedades de las clases principales, sin darse cuenta de que al hacerlo también se omite un proceso de verificación crítico dentro de su código. En general, se deben incluir comprobaciones de autorización a nivel de objeto para cada función que acceda a una fuente de datos mediante una entrada del usuario.

¿Cree que ya los conoce y puede encontrar, corregir y eliminar un error de control de acceso ahora mismo? Juega al desafío gamificado:

¿Cómo te fue? Si quieres mejorar tu puntuación, ¡sigue leyendo!

¿Cuáles son algunos ejemplos de vulnerabilidades de autorización a nivel de objeto incumplidas?

Las vulnerabilidades de control de acceso a nivel de objeto permiten a los atacantes realizar acciones que no se les debería permitir realizar. Esta puede ser una acción que debería reservarse a los administradores, como acceder a datos confidenciales o verlos, o destruir registros. En un entorno de alta seguridad, puede incluso significar impedir que alguien vea los registros a menos que esté específicamente autorizado para hacerlo.
Debe tener en cuenta todas las acciones posibles al definir la autorización a nivel de objeto. Por ejemplo, en la API Java Spring, un punto final con un posible problema podría tener este aspecto:

deleteOrder booleano público (ID largo) {
Pedido = OrderRepository.getOne (id);
si (pedido == nulo) {
log.info («No se encontró ningún pedido»);
devuelve falso;
}
Usuario usuario = Order.getUser ();
OrderRepository.delete (pedido);
log.info («Eliminar pedido para el usuario {}», user.getId ());
devuelve verdadero;

El punto final de la API elimina los pedidos por ID, pero no verifica si este pedido lo ha realizado el usuario que ha iniciado sesión actualmente. Esto brinda a un atacante la oportunidad de aprovechar este vacío legal y eliminar los pedidos de otros usuarios.

Para que las restricciones de acceso seguro se implementen correctamente, el código se parecería más a esto:

deleteOrder booleano público (ID largo) {
Usuario = UserService.getUserByContext ();
booleano orderExist = getUserOrders () .stream ()
.anyMatch (orden -> (Order.getId () == id));
si (OrderExist) {
OrderRepository.deleteById (id);
log.info («Eliminar pedido para el usuario {}», user.getId ());
devuelve verdadero;
} otra cosa {
log.info («No se encontró ningún pedido»);
devuelve falso;

Eliminar las vulnerabilidades de autorización a nivel de objeto roto

El código de control de acceso no tiene por qué ser demasiado complicado. En el caso de nuestro ejemplo de entorno de API Java Spring, se puede solucionar definiendo con precisión quién puede acceder a los objetos.

En primer lugar, se debe implementar un proceso de verificación para identificar quién hace la solicitud:

Usuario = UserService.getUserByContext ();

A continuación, debemos asegurarnos de que el identificador del objeto existe y pertenece al usuario que realiza la solicitud:

booleano orderExist = getUserOrders () .stream ()
.anyMatch (orden -> (Order.getId () == id));

Y por último, procedemos a borrar el objeto:

OrderRepository.deleteById (id);

Ten en cuenta que debes asegurarte de que el método de autorización de tu código se alinee con las políticas de usuario y los controles de acceso a los datos de tu organización. Para garantizar que tu código es totalmente seguro, debes realizar comprobaciones para comprobar que los usuarios con diferentes niveles de permisos tienen acceso a los datos que necesitan para realizar su trabajo, pero no pueden ver ni cambiar nada que esté restringido a ellos. Si lo hace, podría descubrir vulnerabilidades en el control de objetos que faltan y que accidentalmente se han pasado por alto.

Las principales conclusiones de estos ejemplos son definir primero todas las acciones que un usuario podría realizar con un objeto y, a continuación, añadir controles de acceso sólidos directamente al código. Y, por último, nunca confíes en las propiedades principales heredadas para hacer ese trabajo o para delegar esa autoridad en otro lugar. En su lugar, defina los permisos y las acciones de usuario en el código de forma explícita para cada tipo de objeto que necesite proteger.

Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.