Principais vulnerabilidades da API de OATH
Principais vulnerabilidades da API de OATH: introdución
Cando se trata de exploits, as API son o mellor lugar para comezar. API o acceso consta normalmente de tres partes. Os clientes reciben tokens dun servidor de autorización, que se executa xunto coas API. A API recibe tokens de acceso do cliente e aplica regras de autorización específicas de dominio en función delas.
As aplicacións de software modernas son vulnerables a unha variedade de perigos. Mantéñase ao tanto das explotacións e fallos de seguridade máis recentes; ter benchmarks para estas vulnerabilidades é esencial para garantir a seguridade das aplicacións antes de que se produza un ataque. As aplicacións de terceiros dependen cada vez máis do protocolo OAuth. Os usuarios terán unha mellor experiencia de usuario en xeral, así como un inicio de sesión e autorización máis rápidos, grazas a esta tecnoloxía. Pode ser máis seguro que a autorización convencional xa que os usuarios non teñen que revelar as súas credenciais coa aplicación de terceiros para acceder a un determinado recurso. Aínda que o protocolo en si é seguro, a forma en que se implementa pode deixarche aberto a ataques.
Ao deseñar e hospedar API, este artigo céntrase nas vulnerabilidades típicas de OAuth, así como en varias mitigacións de seguridade.
Autorización de nivel de obxecto roto
Hai unha gran superficie de ataque se se viola a autorización xa que as API proporcionan acceso aos obxectos. Dado que os elementos accesibles pola API deben autenticarse, isto é necesario. Implementar comprobacións de autorización a nivel de obxecto mediante unha pasarela de API. Só se lles debe permitir o acceso aqueles que teñan as credenciais de permiso adecuadas.
Autenticación de usuario rota
Os tokens non autorizados son outra forma frecuente para que os atacantes obteñan acceso ás API. É posible que se pirateen os sistemas de autenticación ou que se expoña por erro unha clave de API. Os tokens de autenticación poden ser usado por hackers para adquirir acceso. Autentique as persoas só se se pode confiar en elas e utiliza contrasinais seguros. Con OAuth, podes ir máis alá das simples claves API e acceder aos teus datos. Sempre debes pensar en como entras e saes dun lugar. Os tokens restrinxidos de remitente MTLS de OAuth pódense usar xunto con Mutual TLS para garantir que os clientes non se comporten mal e pasan tokens á parte incorrecta mentres acceden a outras máquinas.
Promoción da API:
Exposición excesiva de datos
Non hai restricións sobre o número de puntos finais que se poden publicar. Na maioría das veces, non todas as funcións están dispoñibles para todos os usuarios. Ao expor máis datos dos absolutamente necesarios, póñase en perigo a vostede e aos demais. Evite revelar información sensible información ata que sexa absolutamente necesario. Os desenvolvedores poden especificar quen ten acceso a que mediante os ámbitos e as reclamacións de OAuth. As reclamacións poden especificar a que seccións dos datos ten acceso un usuario. O control de acceso pode facerse máis sinxelo e fácil de xestionar mediante o uso dunha estrutura estándar en todas as API.
Falta de recursos e limitación de taxas
Os sombreiros negros adoitan usar asaltos de denegación de servizo (DoS) como unha forma de forza bruta de esmagar un servidor e reducir así o seu tempo de actividade a cero. Sen restricións aos recursos que se poden chamar, unha API é vulnerable a un ataque debilitante. "Utilizando unha pasarela de API ou unha ferramenta de xestión, pode establecer restricións de tarifas para as API. Debe incluírse filtrado e paxinación, así como restrinxir as respostas.
Configuración incorrecta do sistema de seguridade
As diferentes directrices de configuración de seguranza son bastante completas, debido á gran probabilidade de que a seguridade se configure incorrectamente. Unha serie de pequenas cousas poden poñer en perigo a seguridade da túa plataforma. É posible que os sombreiros negros con propósitos ulteriores descubran información confidencial enviada en resposta a consultas con formato incorrecto, por exemplo.
Asignación masiva
O feito de que un punto final non estea definido publicamente non implica que os desenvolvedores non poidan acceder a el. Unha API secreta pode ser facilmente interceptada e modificada polos piratas informáticos. Bótalle un ollo a este exemplo básico, que usa un token de portador aberto nunha API "privada". Por outra banda, a documentación pública pode existir para algo que se destina exclusivamente ao uso persoal. Os sombreiros negros poden usar a información exposta non só para ler, senón tamén para manipular as características do obxecto. Considérese un hacker mentres busca potenciais puntos débiles nas súas defensas. Permitir só a aqueles que teñan os dereitos axeitados o acceso ao que foi devolto. Para minimizar a vulnerabilidade, limite o paquete de resposta da API. Os entrevistados non deben engadir ligazóns que non sexan absolutamente necesarias.
API promocionada:
Xestión inadecuada de activos
Ademais de mellorar a produtividade dos desenvolvedores, as versións actuais e a documentación son esenciais para a túa propia seguridade. Prepárese para a introdución de novas versións e para o abandono das antigas API con moita antelación. Usa as API máis novas en lugar de permitir que as antigas sigan en uso. Unha especificación de API podería usarse como fonte principal de verdade para a documentación.
Inxección
As API son vulnerables á inxección, pero tamén o son as aplicacións de desenvolvedores de terceiros. É posible que se use código malicioso para eliminar datos ou roubar información confidencial, como contrasinais e números de tarxeta de crédito. A lección máis importante para sacar isto é non depender da configuración predeterminada. O seu provedor de xestión ou pasarela debería poder atender ás súas necesidades de aplicación únicas. As mensaxes de erro non deben incluír información confidencial. Para evitar que os datos de identidade se filtren fóra do sistema, os seudónimos por parellas deben usarse nos tokens. Isto garante que ningún cliente poida traballar xunto para identificar un usuario.
Rexistro e seguimento insuficientes
Cando se produce un ataque, os equipos requiren unha estratexia de reacción ben pensada. Os desenvolvedores seguirán explotando as vulnerabilidades sen ser detectados se non existe un sistema de rexistro e seguimento fiable, o que aumentará as perdas e prexudicará a percepción do público sobre a empresa. Adopte unha estrita estratexia de seguimento da API e probas de puntos finais de produción. Os probadores de sombreiro branco que atopen vulnerabilidades desde un principio deberían ser recompensados cun esquema de recompensas. O rexistro de rexistro pódese mellorar incluíndo a identidade do usuario nas transaccións da API. Asegúrate de que todas as capas da túa arquitectura de API sexan auditadas mediante os datos do token de acceso.
Conclusión
Os arquitectos de plataforma poden equipar os seus sistemas para manterse un paso por diante dos atacantes seguindo os criterios de vulnerabilidade establecidos. Dado que as API poden proporcionar accesibilidade á información de identificación persoal (PII), manter a seguridade destes servizos é fundamental tanto para a estabilidade da empresa como para o cumprimento da lexislación como o GDPR. Nunca envíe tokens de OAuth directamente a través dunha API sen utilizar unha pasarela de API e o enfoque Phantom Token.
API promocionada:
