Harden contra la escalada de privilegios en microservicios

Question

Harden contra la escalada de privilegios en microservicios

#1 de Trim Kadriu (0 votos)

0

Considere el siguiente escenario.

El sistema tiene un conjunto de propietarios de negocios (es decir, usuarios del sistema)
Cada propietario de empresa se asigna a un conjunto de clientes
Los propietarios de negocios inician sesión en el sistema para administrar sus clientes.

Los propietarios de negocios seleccionarán un solo cliente primero, y de ahí en adelante su sesión estará vinculada a ese cliente seleccionado .

Tengo un conjunto de microservicios, cada uno requiere un Customer-ID para su procesamiento. es decir,

El microservicio A expone GET /resource-a/{customer-id}
El microservicio B expone POST /resource-b/{customer-id}
etc.

El Customer-Id se considera una información confidencial, por lo que se encuentra en forma cifrada.

Sin embargo, sigue siendo vulnerable a escalada de privilegios . es decir, un propietario de un negocio puede compartir erróneamente la identificación del cliente cifrada a través de marcadores, etc. para que el propietario de un negocio pueda acceder a los detalles de los clientes que no están asignados a él. (¿No es exactamente una escalada de privilegios?)

Quiero evitar la autorización del lado del servidor de la identificación del cliente contra el propietario de la empresa porque se sabe que es una operación lenta y el 90% de las API tendrá que repetir este proceso de autorización
Todos los microservicios son sin estado, por lo que no es posible cifrar el Customer-Id con el id de sesión como la clave (ya que no hay microservicios / sesión con estado)
Además, no creo que sea una buena idea hacer esta autorización en la puerta de enlace, ya que no está diseñada para llevar a cabo tal lógica de negocios.

¿Cómo puedo evitar la escalada de privilegios en esta situación?

encryption session-management privilege-escalation

pregunta Fahim Farook 21.10.2018 - 10:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption session-management privilege-escalation

SSLSPLIT no funciona con WSS ¿Cuál es la diferencia entre los casos de mal uso y abuso en la seguridad?

score 0 · Answer 1

Teniendo en cuenta que no quieres hacer esto en el lado del servidor, solo veo otras dos posibilidades:

Vaya con security through obscurity , y nunca exponga Customer-Id en la vista del usuario (cualquier acción que lo haga aparecer en la barra de direcciones, la interfaz de usuario, el historial del navegador, etc.). Esto no solucionará su problema y no lo protegerá contra un atacante dedicado. Aunque podría funcionar en cierto grado.
Use tokens autónomos sin estado (por ejemplo, JWT) para generar la sesión del usuario. Y almacene todos los customer-id's que están vinculados a ese usuario en el token. Luego, cuando verifique el token del servidor de sesión, también obtendrá autorización al mismo tiempo. Esto no costaría en absoluto el rendimiento. Sin embargo, podría funcionar como una solución solo en la medida en que no tenga mucho% a_de% vinculado a un usuario (obviamente, no quiere que toda la base de datos esté en el token).

Soy consciente de que esta podría no ser la respuesta completa, y preferiría agregar esto como un comentario, pero no pude hacerlo debido a mi reputación. Por lo tanto, pediría que se abstengan de dar puntos negativos.