Las amenazas a la ciberseguridad hoy en día son omnipresentes e implacables. Se ha vuelto tan grave que tratar de mantenerse al día con ellas después de desplegar los programas se ha vuelto casi imposible. Sin embargo, en esta época de DevSecOps, entrega continua y más datos que nunca, las organizaciones astutas están ayudando a sus desarrolladores a convertirse en superestrellas conscientes de la seguridad que ayudan a eliminar las vulnerabilidades comunes antes de que lleguen a la producción. Hemos abordado las vulnerabilidades de la web, además de nuestros 8 principales errores de la Infraestructura como Código, y ahora es el momento de familiarizarse con el próximo gran desafío de la seguridad del software. ¿Está usted preparado?

Esta próxima serie de blogs se centrará en algunos de los peores fallos de seguridad relacionados con las interfaces de programación de aplicaciones (API). Estos son tan malos que han llegado a la lista de las principales vulnerabilidades de las API del Proyecto de Seguridad de Aplicaciones Web Abiertas(OWASP). Dada la importancia de las APIs en las infraestructuras informáticas modernas, se trata de problemas críticos que debes mantener fuera de tus aplicaciones y programas a toda costa.

Un ejemplo perfecto de por qué es esencial utilizar el 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 explícitamente qué usuarios pueden ver los objetos y los datos, ni proporcionan ninguna forma de verificación para ver, cambiar o hacer otras solicitudes para manipular o acceder a los objetos, permitiéndoles modificar y acceder a los objetos y datos 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 aplicaciones ha elevado algunos de los programas más queridos del mundo, pero conlleva el riesgo de exponer múltiples puntos finales si no son herméticos.

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

¿Crees que ya estás familiarizado con ellos y que puedes encontrar, arreglar y eliminar un error de control de acceso ahora mismo? Juega al reto gamificado:

¿Qué tal te ha ido? Si quieres mejorar tu puntuación, ¡sigue leyendo!

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

Las vulnerabilidades de control de acceso a nivel de objeto permiten a los atacantes realizar acciones que no deberían estar permitidas. Puede tratarse de una acción que debería estar reservada a los administradores, como el acceso o la visualización de datos sensibles, o la destrucción de registros. En un entorno de alta seguridad, incluso podría significar impedir que cualquier persona vea los registros a menos que esté específicamente autorizada para hacerlo.
Debes tener en cuenta todas las acciones posibles al definir la autorización a nivel de objeto. Por ejemplo, en la API de Java Spring, un punto final con un problema potencial podría tener este aspecto:

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

El punto final de la API elimina los pedidos por ID, pero no verifica si este pedido ha sido realizado por el usuario que ha iniciado la sesión. Esto supone una oportunidad para que un atacante aproveche esta laguna y elimine los pedidos de otros usuarios.

Para que las restricciones de acceso seguras se apliquen correctamente, el código se vería más bien así:

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

Eliminación de las vulnerabilidades de autorización a nivel de objetos rotos

El código de control de acceso no tiene por qué ser excesivamente complicado. En el caso de nuestro ejemplo del entorno de la API de Java Spring, se puede arreglar definiendo estrictamente quién puede acceder a los objetos.

En primer lugar, hay que poner en marcha un proceso de verificación para identificar quién hace la solicitud:

Usuario = userService.getUserByContext();

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

boolean orderExist = getUserOrders().stream()
.anyMatch(order -> (order.getId() == id));

Y por último, procedemos a eliminar el objeto:

orderRepository.deleteById(id);

Ten en cuenta que debes asegurarte de que el método de autorización en tu código se alinea con las políticas de usuario y los controles de acceso a los datos de tu organización. Como forma de garantizar que su código es totalmente seguro, debe realizar comprobaciones para verificar que los usuarios con diferentes niveles de permiso tienen acceso a los datos que necesitan para realizar su trabajo, pero se les impide ver o cambiar cualquier cosa que debería estar restringida a ellos. Hacerlo podría descubrir vulnerabilidades de control de objetos que se han pasado por alto accidentalmente.

Lo principal que se desprende de estos ejemplos es que primero hay que definir todas las acciones que un usuario podría realizar con un objeto, y luego añadir fuertes controles de acceso directamente al código. Y por último, nunca confíes en las propiedades heredadas de los padres para hacer ese trabajo o delegar esa autoridad en otro lugar. En su lugar, define los permisos y acciones de los usuarios en el código de forma explícita para cada tipo de objeto que necesites proteger.

Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.