Header Ads Widget

Ticker

6/recent/ticker-posts

Principales vulnerabilidades de la API de OAuth

 

Las API son el lugar donde protege los datos, y este es el mejor lugar para comenzar a pensar en exploits. Normalmente, el acceso a la API implica tres tipos de componentes. Un servidor de autorización se aloja junto con las API y emite tokens a los clientes. Un cliente envía tokens de acceso a la API, que luego los usa para aplicar reglas de autorización específicas del dominio.

Este artículo se centra en las vulnerabilidades comunes de OAuth al desarrollar y alojar API, junto con algunas mitigaciones para mejorar la seguridad.

1. Fichas filtradas
Hay un par de cosas básicas que las empresas que crean API siempre deben hacer bien:

Asegúrese de que las API no se puedan llamar a través de URL HTTP simples.
Asegúrese de que los tokens de acceso se envíen en el encabezado de autorización HTTP .
Los tokens de acceso no deben enviarse en URL, como a través de parámetros de consulta, ya que luego pueden registrarse en los registros del servidor HTTP, lo que podría explotarse.

Además, intente evitar la construcción de sus propias tiendas de tokens de back-end, que luego deben protegerse. En su lugar, deje que el servidor de autorización administre el almacenamiento de tokens por usted.

2. Validación del token de acceso débil
Las API deben verificar digitalmente los JWT en cada solicitud, y la solución más común para esto es a través de una clave pública asimétrica descargada del servidor de autorización. Hay muchas bibliotecas de seguridad respetadas en diversas tecnologías que se pueden utilizar para realizar criptografía de bajo nivel.

Una vulnerabilidad conocida es que un atacante envíe un JWT con un algoritmo nulo en el encabezado JWT, lo que posiblemente les permita manipular los tokens que envían:

  • alg: ninguno
En lugar de aceptar esto, la API debe especificar los algoritmos en los que confía y utilizar un valor seguro como RS256 o ES256. Los siguientes detalles genéricos también deben verificarse para asegurarse de que tengan valores válidos:

Emisor: debe coincidir con el valor del servidor de autorización.
Caducidad: la hora actual debe estar entre los valores nbfy el token exp.
Audiencia : representa un conjunto de una o más API relacionadas.
Si estas comprobaciones no se realizan correctamente, existen oportunidades para exploits, aunque cualquier buena biblioteca de validación de JWT debería facilitar el procesamiento adecuado.

3. Alcances insuficientes
Los alcances de OAuth son permisos de alto nivel para controlar las áreas de datos a las que puede acceder un token y qué operaciones se pueden realizar en esos datos, como en estos ejemplos:

  • orders_write
  • inventory_read
Los ámbitos proporcionan otro nivel de defensa para que no dependa únicamente del código API para realizar la autorización correctamente. Si se usa un alcance que lo abarca todo, como allo default, esto permite que un atacante intente usar un token de acceso en todos los puntos finales de la API.

Utilice ámbitos para habilitar el acceso de grano grueso. El middleware, como un proxy inverso, puede rechazar solicitudes obviamente inválidas enviadas por un atacante. Esto también puede ahorrar costos en algunas configuraciones.

4. Reclamaciones no verificadas
Los valores importantes relacionados con la seguridad como los que a continuación deben ser incluidos como reclamaciones en JWTs enviados a las API, en las que actúan como valores reivindicados por el servidor de autorización. Una vez que la API verifica digitalmente el JWT, puede confiar en estos valores y usarlos para la autorización:

  • ID de usuario = 27890345
  • ID de la empresa = 890234
  • Rol = superusuario
  • Alcance = pago de perfil openid
No reciba estos valores en las API a través de segmentos de ruta de URL, parámetros de consulta o encabezados HTTP, donde no son verificables, ya que esto habilita exploits donde un atacante puede cambiar la entrada y potencialmente obtener acceso no autorizado.

5. Datos privados filtrados
Aunque las API necesitan reclamos de autorización, los detalles no deben filtrarse a los clientes de Internet, que en su lugar deben usar tokens de acceso opacos que no revelen ningún detalle confidencial.

Esto se gestiona mejor colocando un proxy inverso frente a las API y usándolo para lidiar con el intercambio de tokens, como se describe en este artículo de Curity sobre el patrón de token fantasma :

  • El servidor de autorización guarda los detalles de las reclamaciones emitidas.
  • El servidor de autorización emite tokens de acceso a los clientes de Internet en un formato de token de referencia.
  • El cliente envía el token de referencia a través del proxy inverso a las API.
  • Los introspectivos del proxy inverso recibieron tokens de acceso para obtener reclamos en un JWT.
  • El proxy inverso reenvía el JWT a las API.
  • Las API verifican digitalmente el JWT y utilizan sus reclamos para la autorización.
6. Autorización de nivel de objeto roto
Es esencial que las empresas que desarrollan API puedan controlar las reclamaciones emitidas en los JWT para que puedan realizar su autorización específica de dominio. Esto generalmente se basa en reglas relacionadas con la propiedad de los datos:

  • Un paciente solo debe poder ver su propio historial médico.
  • Un médico solo debe poder ver los registros de pacientes para cirugías particulares.
  • Un cliente solo debe poder ver productos para su nivel de suscripción.
  • Es posible que su propia aplicación solo envíe solicitudes en función de la identificación del usuario que haya iniciado sesión actualmente, pero un atacante podría enviar solicitudes de API a través de herramientas como curl y cambiar las ID a las de otros usuarios.

Asegúrese de que los JWT entregados a las API contengan los reclamos necesarios. Por lo general, esto requerirá la capacidad del servidor de autorización para leer las reclamaciones específicas del dominio en el momento de la emisión del token.

7. Diseño de infraestructura de API débil
Al diseñar el alojamiento, se recomienda evitar exponer los servidores que acceden a las fuentes de datos directamente a Internet. En su lugar, se debe colocar un proxy inverso frente a ellos para que, si un atacante viola la primera capa, no pueda acceder a las fuentes de datos.

Otra decisión es decidir a qué API pueden acceder los clientes de Internet. Si todos los microservicios están expuestos, la superficie de ataque es mayor. Esto lleva a algunas empresas a categorizar las API y utilizar las redes para exponer solo las API de Internet en lugar de los microservicios centrales.

8. Seguridad de microservicios débil
El tipo de configuración de infraestructura anterior puede llevar a recortar esquinas de seguridad en microservicios:

Las API de Internet validan los JWT correctamente.
Luego, las API de Internet pasan las reclamaciones en los encabezados a los microservicios centrales.
Evite esto ya que es vulnerable a las vulnerabilidades de Man in the Middle (MITM). En su lugar, utilice un enfoque de confianza cero , donde todas las API validan los tokens de acceso en cada solicitud:

En la memoria, la validación de JWT es rápida y está diseñada para escalar.
Los tokens de acceso generalmente se pueden reenviar directamente entre microservicios.
Luego, todas las API operan de forma segura mediante afirmaciones verificables, y los atacantes deben obtener un JWT válido antes de poder llamar a cualquiera de sus API.

9. Registro insuficiente
El acceso a los datos confidenciales también debe auditarse, y esta es un área en la que los sistemas de administración de identidades y accesos (IAM) pueden hacer gran parte del trabajo por usted:

  • Utilice el servidor de autorización para registrar detalles de qué reclamos y ámbitos se emitieron y para qué clientes y usuarios.
  • Almacene la información de identificación personal (PII) en el servidor de autorización para que el consentimiento del usuario se pueda integrar fácilmente y los cambios en los usuarios se auditen.
  • Considere el uso de un sistema de gestión de derechos que proporcione auditorías adicionales durante las solicitudes de API.
Conclusión
Diseñar un back-end seguro para su plataforma de software requiere conocimientos, pero al seguir los patrones de diseño de OAuth, puede administrar la seguridad de API a escala, con solo un código simple. Para obtener recursos adicionales relacionados, consulte las 10 principales vulnerabilidades de la API de OWASP y nuestra publicación sobre las principales vulnerabilidades de los clientes de OAuth.


Publicar un comentario

0 Comentarios