Principales vulnerabilidades de la API de OATH
Principales vulnerabilidades de la API de OATH: Introducción
Cuando se trata de exploits, las API son el mejor lugar para comenzar. API el acceso suele constar de tres partes. Los clientes reciben tokens de un servidor de autorización, que se ejecuta junto con las API. La API recibe tokens de acceso del cliente y aplica reglas de autorización específicas del dominio en función de ellos.
Las aplicaciones de software modernas son vulnerables a una variedad de peligros. Manténgase al día sobre las vulnerabilidades y fallas de seguridad más recientes; tener puntos de referencia para estas vulnerabilidades es esencial para garantizar la seguridad de la aplicación antes de que ocurra un ataque. Las aplicaciones de terceros dependen cada vez más del protocolo OAuth. Los usuarios tendrán una mejor experiencia de usuario en general, así como un inicio de sesión y una autorización más rápidos, gracias a esta tecnología. Puede ser más seguro que la autorización convencional, ya que los usuarios no tienen que revelar sus credenciales con la aplicación de terceros para acceder a un recurso determinado. Si bien el protocolo en sí es seguro y protegido, la forma en que se implementa puede dejarlo expuesto a ataques.
Al diseñar y alojar API, este artículo se centra en las vulnerabilidades típicas de OAuth, así como en varias mitigaciones de seguridad.
Autorización de nivel de objeto roto
Existe una gran superficie de ataque si se viola la autorización, ya que las API brindan acceso a los objetos. Dado que los elementos accesibles por API deben autenticarse, esto es necesario. Implemente verificaciones de autorización a nivel de objeto mediante una puerta de enlace API. Solo se debe permitir el acceso a aquellos con las credenciales de permiso adecuadas.
Autenticación de usuario rota
Los tokens no autorizados son otra forma frecuente de que los atacantes obtengan acceso a las API. Los sistemas de autenticación pueden ser pirateados o una clave API puede estar expuesta por error. Los tokens de autenticación pueden ser utilizado por piratas informáticos para adquirir acceso. Autentique a las personas solo si se puede confiar en ellas y use contraseñas seguras. Con OAuth, puede ir más allá de las meras claves API y obtener acceso a sus datos. Siempre debes pensar en cómo entrarás y saldrás de un lugar. Los tokens restringidos del remitente de MTLS de OAuth se pueden usar junto con Mutual TLS para garantizar que los clientes no se porten mal y pasen los tokens a la parte incorrecta mientras acceden a otras máquinas.
Promoción API:
Exposición excesiva de datos
No hay restricciones sobre el número de puntos finales que se pueden publicar. La mayoría de las veces, no todas las funciones están disponibles para todos los usuarios. Al exponer más datos de los absolutamente necesarios, se pone a sí mismo y a otros en peligro. Evite revelar datos confidenciales información hasta que sea absolutamente necesario. Los desarrolladores pueden especificar quién tiene acceso a qué al utilizar OAuth Scopes and Claims. Las reclamaciones pueden especificar a qué secciones de los datos tiene acceso un usuario. El control de acceso se puede hacer más simple y más fácil de administrar mediante el uso de una estructura estándar en todas las API.
Falta de recursos y limitación de tarifas
Los black hats a menudo usan ataques de denegación de servicio (DoS) como una forma de fuerza bruta de saturar un servidor y así reducir su tiempo de actividad a cero. Sin restricciones en los recursos a los que se puede llamar, una API es vulnerable a un ataque debilitante. 'Usando una puerta de enlace API o una herramienta de administración, puede establecer restricciones de tarifas para las API. Se debe incluir el filtrado y la paginación, así como restringir las respuestas.
Configuración incorrecta del sistema de seguridad
Las diferentes pautas de configuración de seguridad son bastante completas, debido a la probabilidad significativa de una mala configuración de seguridad. Una serie de pequeñas cosas pueden poner en peligro la seguridad de su plataforma. Es posible que los sombreros negros con fines ulteriores puedan descubrir información confidencial enviada en respuesta a consultas mal formadas, por ejemplo.
Asignación masiva
El hecho de que un punto final no esté definido públicamente no implica que los desarrolladores no puedan acceder a él. Los piratas informáticos pueden interceptar fácilmente una API secreta y realizar ingeniería inversa. Eche un vistazo a este ejemplo básico, que utiliza un token de portador abierto en una API "privada". Por otro lado, la documentación pública puede existir para algo que está destinado exclusivamente para uso personal. La información expuesta puede ser utilizada por los sombreros negros no solo para leer, sino también para manipular las características del objeto. Considérese un hacker mientras busca posibles puntos débiles en sus defensas. Permita que solo aquellos con los derechos adecuados accedan a lo que se devolvió. Para minimizar la vulnerabilidad, limite el paquete de respuesta de la API. Los encuestados no deben agregar ningún enlace que no sea absolutamente necesario.
API promocionada:
Gestión inadecuada de activos
Además de mejorar la productividad del desarrollador, las versiones y la documentación actuales son esenciales para su propia seguridad. Prepárese para la introducción de nuevas versiones y la obsolescencia de las API antiguas con mucha antelación. Use API más nuevas en lugar de permitir que las más antiguas permanezcan en uso. Se podría utilizar una especificación de API como fuente principal de información para la documentación.
Inyección
Las API son vulnerables a la inyección, pero también lo son las aplicaciones de desarrolladores de terceros. El código malicioso se puede usar para eliminar datos o robar información confidencial, como contraseñas y números de tarjetas de crédito. La lección más importante que podemos sacar de esto es no depender de la configuración predeterminada. Su proveedor de administración o puerta de enlace debe poder adaptarse a sus necesidades únicas de aplicación. Los mensajes de error no deben incluir información confidencial. Para evitar que los datos de identidad se filtren fuera del sistema, se deben usar seudónimos por parejas en tokens. Esto asegura que ningún cliente pueda trabajar en conjunto para identificar a un usuario.
Registro y monitoreo insuficientes
Cuando ocurre un ataque, los equipos requieren una estrategia de reacción bien pensada. Los desarrolladores continuarán explotando las vulnerabilidades sin ser descubiertos si no se cuenta con un sistema confiable de registro y monitoreo, lo que aumentará las pérdidas y dañará la percepción que el público tiene de la empresa. Adopte una estricta estrategia de pruebas de punto final de producción y supervisión de API. Los probadores de sombrero blanco que encuentren vulnerabilidades desde el principio deben ser recompensados con un esquema de recompensas. El seguimiento del registro puede mejorarse al incluir la identidad del usuario en las transacciones de la API. Asegúrese de que todas las capas de su arquitectura de API se auditen mediante el uso de datos de token de acceso.
Conclusión
Los arquitectos de plataformas pueden equipar sus sistemas para mantenerse un paso por delante de los atacantes siguiendo los criterios de vulnerabilidad establecidos. Debido a que las API pueden proporcionar acceso a la información de identificación personal (PII), mantener la seguridad de dichos servicios es fundamental tanto para la estabilidad de la empresa como para el cumplimiento de la legislación como GDPR. Nunca envíe tokens de OAuth directamente a través de una API sin usar una puerta de enlace de API y el enfoque de token fantasma.
API promocionada:
