Principals vulnerabilitats de l'API OATH
Vulnerabilitats principals de l'API OATH: introducció
Quan es tracta d'explotacions, les API són el millor lloc per començar. API l'accés normalment consta de tres parts. Els clients reben testimonis mitjançant un servidor d'autoritzacions, que s'executa juntament amb les API. L'API rep testimonis d'accés del client i aplica regles d'autorització específiques del domini en funció d'elles.
Les aplicacions de programari modernes són vulnerables a una varietat de perills. Manteniu-vos al dia de les explotacions i defectes de seguretat més recents; tenir punts de referència per a aquestes vulnerabilitats és essencial per garantir la seguretat de les aplicacions abans que es produeixi un atac. Les aplicacions de tercers depenen cada cop més del protocol OAuth. Els usuaris tindran una millor experiència d'usuari global, així com un inici de sessió i autorització més ràpids gràcies a aquesta tecnologia. Pot ser més segur que l'autorització convencional, ja que els usuaris no han de revelar les seves credencials amb l'aplicació de tercers per accedir a un recurs determinat. Tot i que el protocol en si és segur i segur, la forma en què s'implementa pot deixar-vos obert a atacs.
Quan es dissenyen i allotgen API, aquest article se centra en les vulnerabilitats típiques d'OAuth, així com en diverses mitigacions de seguretat.
Autorització a nivell d'objecte trencat
Hi ha una gran superfície d'atac si es viola l'autorització, ja que les API proporcionen accés als objectes. Com que els elements accessibles per l'API s'han d'autenticar, això és necessari. Implementeu comprovacions d'autorització a nivell d'objecte mitjançant una passarel·la d'API. Només se'ls hauria de permetre l'accés a aquells que tinguin les credencials de permís adequades.
Autenticació d'usuari trencada
Els testimonis no autoritzats són una altra manera freqüent per als atacants d'obtenir accés a les API. Els sistemes d'autenticació poden ser piratejats o una clau d'API es pot exposar per error. Els testimonis d'autenticació poden ser utilitzat pels pirates informàtics per adquirir accés. Autentiqueu les persones només si es pot confiar en elles i feu servir contrasenyes segures. Amb OAuth, podeu anar més enllà de les simples claus API i accedir a les vostres dades. Sempre hauríeu de pensar com entrareu i sortireu d'un lloc. Els testimonis restringits del remitent d'OAuth MTLS es poden utilitzar conjuntament amb el TLS mutu per garantir que els clients no es comporten malament i que passen testimonis a la part incorrecta mentre accedeixen a altres màquines.
Promoció de l'API:
Excessiva exposició de dades
No hi ha restriccions sobre el nombre de punts finals que es poden publicar. La majoria de les vegades, no totes les funcions estan disponibles per a tots els usuaris. En exposar més dades de les que són absolutament necessàries, et poses a tu mateix i als altres en perill. Eviteu revelar informació sensible informació fins que sigui absolutament necessari. Els desenvolupadors poden especificar qui té accés a què utilitzant els àmbits i les reclamacions d'OAuth. Les reclamacions poden especificar a quines seccions de les dades té accés un usuari. El control d'accés es pot fer més senzill i més fàcil de gestionar mitjançant l'ús d'una estructura estàndard a totes les API.
Manca de recursos i limitació de tarifes
Els barrets negres sovint utilitzen atacs de denegació de servei (DoS) com a forma de força bruta d'aclaparar un servidor i reduir així el seu temps de funcionament a zero. Sense restriccions sobre els recursos que es poden cridar, una API és vulnerable a un assalt debilitant. "Usant una passarel·la d'API o una eina de gestió, podeu establir restriccions de tarifes per a les API. S'han d'incloure el filtratge i la paginació, així com les respostes restringides.
Configuració incorrecta del sistema de seguretat
Les diferents directrius de configuració de seguretat són bastant completes, a causa de la gran probabilitat d'una configuració incorrecta de la seguretat. Una sèrie de petites coses poden posar en perill la seguretat de la vostra plataforma. És possible que els barrets negres amb finalitats posteriors puguin descobrir informació sensible enviada en resposta a consultes amb un format incorrecte, per exemple.
Encàrrec massiu
El fet que un punt final no estigui definit públicament no implica que els desenvolupadors no puguin accedir-hi. Els pirates informàtics poden interceptar i fer enginyeria inversa fàcilment una API secreta. Fes una ullada a aquest exemple bàsic, que utilitza un testimoni de portador obert en una API "privada". D'altra banda, la documentació pública pot existir per a quelcom que es destina exclusivament a l'ús personal. Els barrets negres poden utilitzar la informació exposada no només per llegir sinó també per manipular les característiques dels objectes. Considereu-vos un pirata informàtic mentre cerqueu possibles punts febles en les vostres defenses. Permeteu que només aquells que tinguin els drets adequats accedeixin al que s'ha retornat. Per minimitzar la vulnerabilitat, limiteu el paquet de resposta de l'API. Els enquestats no haurien d'afegir cap enllaç que no sigui absolutament obligatori.
API promocionada:
Gestió inadequada d'actius
A part de millorar la productivitat dels desenvolupadors, les versions i la documentació actuals són essencials per a la vostra seguretat. Prepareu-vos per a la introducció de noves versions i l'abandonament de les antigues API amb molta antelació. Utilitzeu API més noves en lloc de permetre que les més antigues es mantinguin en ús. Una especificació d'API es podria utilitzar com a font principal de veritat per a la documentació.
Injecció
Les API són vulnerables a la injecció, però també ho són les aplicacions de desenvolupadors de tercers. Es pot utilitzar codi maliciós per suprimir dades o robar informació confidencial, com ara contrasenyes i números de targetes de crèdit. La lliçó més important que cal treure d'això és no dependre de la configuració predeterminada. El vostre proveïdor de gestió o passarel·la hauria de poder satisfer les vostres necessitats úniques d'aplicació. Els missatges d'error no han d'incloure informació sensible. Per evitar que les dades d'identitat es filtrin fora del sistema, els pseudònims per parelles s'han d'utilitzar als testimonis. Això garanteix que cap client pugui treballar conjuntament per identificar un usuari.
Registre i seguiment insuficients
Quan es produeix un atac, els equips requereixen una estratègia de reacció ben pensada. Els desenvolupadors continuaran explotant les vulnerabilitats sense ser detectats si no hi ha un sistema de registre i monitoratge fiable, la qual cosa augmentarà les pèrdues i danyarà la percepció del públic de l'empresa. Adopteu una estricta estratègia de control de l'API i proves de punt final de producció. Els provadors de barret blanc que troben vulnerabilitats des del principi haurien de ser recompensats amb un esquema de recompenses. El registre de registre es pot millorar si inclou la identitat de l'usuari a les transaccions de l'API. Assegureu-vos que totes les capes de l'arquitectura de l'API s'avaluïn mitjançant les dades del testimoni d'accés.
Conclusió
Els arquitectes de plataforma poden equipar els seus sistemes per mantenir-se un pas per davant dels atacants seguint els criteris de vulnerabilitat establerts. Com que les API poden proporcionar accessibilitat a la informació d'identificació personal (PII), mantenir la seguretat d'aquests serveis és fonamental tant per a l'estabilitat de l'empresa com per al compliment de la legislació com ara el GDPR. No envieu mai fitxes OAuth directament a través d'una API sense utilitzar una passarel·la d'API i l'enfocament de fitxes fantasma.
API promocionada:
