Supraj Vundeblaj API de OATH
Supraj Vundeblaj API de OATH: Enkonduko
Kiam temas pri ekspluatoj, APIoj estas la plej bonega loko por komenci. API aliro kutime konsistas el tri partoj. Klientoj estas eldonitaj ĵetonoj fare de Rajtiga Servilo, kiu funkcias kune kun APIoj. La API ricevas alirĵetonojn de la kliento kaj aplikas domajn-specifajn rajtigajn regulojn bazitajn sur ili.
Modernaj programoj estas vundeblaj al diversaj danĝeroj. Konservu rapide pri la plej lastatempaj atingoj kaj sekurecaj difektoj; havi komparnormojn por ĉi tiuj vundeblecoj estas esenca por certigi aplikaĵan sekurecon antaŭ ol atako okazas. Triaj aplikaĵoj ĉiam pli dependas de la OAuth-protokolo. Uzantoj havos pli bonan ĝeneralan uzantan sperton, kaj pli rapidan ensaluton kaj rajtigon, danke al ĉi tiu teknologio. Ĝi povas esti pli sekura ol konvencia rajtigo ĉar uzantoj ne devas malkaŝi siajn akreditaĵojn kun la triaparta aplikaĵo por aliri difinitan rimedon. Dum la protokolo mem estas sekura kaj sekura, la maniero kiel ĝi estas efektivigita eble lasos vin malfermita por ataki.
Dum desegnado kaj gastigado de API-oj, ĉi tiu artikolo temigas tipajn vundeblecojn de OAuth, kaj ankaŭ diversajn sekurecajn mildigojn.
Rompita Objekta Nivela Rajto
Estas vasta ataksurfaco se rajtigo estas malobservita ĉar API-oj disponigas aliron al objektoj. Ĉar API-alireblaj eroj devas esti aŭtentikigitaj, tio estas necesa. Efektivigu objektnivelajn rajtigajn kontrolojn uzante API-enirejon. Nur tiuj kun la taŭgaj permesaj akreditaĵoj estu permesitaj aliro.
Rompita Uzanto-Aŭtentikigo
Neaŭtorizitaj ĵetonoj estas alia ofta maniero por atakantoj akiri aliron al APIoj. Aŭtentikigsistemoj povas esti hakitaj, aŭ API-ŝlosilo povas esti erare elmontrita. Aŭtentigaj signoj povas esti uzata de hackers akiri aliron. Aŭtentikigu homojn nur se ili povas esti fidindaj, kaj uzu fortajn pasvortojn. Kun OAuth, vi povas iri preter nuraj API-ŝlosiloj kaj akiri aliron al viaj datumoj. Vi ĉiam devus pensi pri kiel vi eniros kaj eliros el loko. OAuth MTLS Sender Constrained Tokens povas esti uzataj kune kun Mutual TLS por garantii, ke klientoj ne miskondutas kaj transdonas ĵetonojn al la malĝusta partio dum aliro al aliaj maŝinoj.
API-Reklamo:
Troa Eksponado de Datumoj
Ekzistas neniuj limoj pri la nombro da finpunktoj kiuj povas esti publikigitaj. Plejofte, ne ĉiuj funkcioj estas disponeblaj por ĉiuj uzantoj. Eksponante pli da datumoj ol nepre necesas, vi endanĝerigas vin kaj aliajn. Evitu malkaŝi sentema informo ĝis ĝi estos nepre necesa. Programistoj povas specifi kiu havas aliron al kio uzante OAuth Scopes kaj Claims. Asertoj povas specifi al kiuj sekcioj de la datumoj uzanto havas aliron. Alirkontrolo povas fariĝi pli simpla kaj pli facile administrebla uzante norman strukturon tra ĉiuj APIoj.
Manko de Rimedoj & Indice Limigo
Nigraj ĉapeloj ofte uzas neon de servo (DoS) atakojn kiel krudfortan manieron superforti servilon kaj tiel redukti ĝian funkciadon al nulo. Sen limigoj pri la rimedoj, kiujn oni povas nomi, API estas vundebla al malfortiga atako. 'Uzante API-enirejon aŭ administran ilon, vi povas agordi tariflimojn por API-oj. Filtrilo kaj paĝigo devus esti inkluzivitaj, same kiel respondoj limigitaj.
Misagordo De La Sekureca Sistemo
Malsamaj sekurecaj agordaj gvidlinioj estas sufiĉe ampleksaj, pro la grava verŝajneco de sekureca misagordo. Kelkaj etaj aferoj povus endanĝerigi la sekurecon de via platformo. Eblas, ke nigraj ĉapeloj kun kaŝaj celoj povas malkovri sentemajn informojn senditajn en respondo al misformitaj demandoj, ekzemple.
Amasa Tasko
Nur ĉar finpunkto ne estas publike difinita, tio ne implicas ke ĝi ne povas esti alirebla de programistoj. Sekreta API povas esti facile kaptita kaj invers-inĝenierita de retpiratoj. Rigardu ĉi tiun bazan ekzemplon, kiu uzas malferman Bearer Token en "privata" API. Aliflanke, publika dokumentaro povas ekzisti por io kiu estas ekskluzive signifita por persona uzo. Senŝirmaj informoj povas esti uzataj de nigraj ĉapeloj por ne nur legi sed ankaŭ manipuli objektokarakterizaĵojn. Konsideru vin retpirato dum vi serĉas eblajn malfortajn punktojn en viaj defendoj. Permesu nur al tiuj, kiuj havas taŭgajn rajtojn, aliron al tio, kio estis resendita. Por minimumigi vundeblecon, limigu la respondpakaĵon de API. Respondantoj ne devas aldoni iujn ajn ligilojn kiuj ne estas absolute postulataj.
Antaŭenigita API:
Nekonvena Aktivadministrado
Krom plibonigi la produktivecon de programistoj, aktualaj versioj kaj dokumentaro estas esencaj por via propra sekureco. Preparu por la enkonduko de novaj versioj kaj la malrekomendigo de malnovaj APIoj longe anticipe. Uzu pli novajn API-ojn anstataŭ permesi al pli malnovaj resti uzataj. API Specifo povus esti uzata kiel ĉefa fonto de vero por dokumentado.
Injekto
APIoj estas vundeblaj al injekto, sed ankaŭ estas triaj programistoj. Malica kodo povas esti uzata por forigi datumojn aŭ ŝteli konfidencajn informojn, kiel pasvortojn kaj kreditkartajn nombrojn. La plej grava leciono por preni de ĉi tio estas ne dependi de la defaŭltaj agordoj. Via administrado aŭ enirejo provizanto devus povi akomodi viajn unikajn aplikajn bezonojn. Erarmesaĝoj ne devus inkluzivi sentemajn informojn. Por malhelpi identecajn datumojn liki ekster la sistemon, Duopaj Pseŭdonimoj devas esti uzataj en ĵetonoj. Ĉi tio certigas, ke neniu kliento povas kunlabori por identigi uzanton.
Nesufiĉa Registrado Kaj Monitorado
Kiam atako okazas, teamoj postulas bone pripensitan reagstrategion. Programistoj daŭre ekspluatos vundeblecojn sen esti kaptitaj se fidinda registra kaj monitora sistemo ne estas en loko, kio pliigos perdojn kaj difektos la percepton de la publiko pri la kompanio. Adoptu striktan API-monitoradon kaj produktadfinan testan strategion. Blankĉapelaj testistoj, kiuj frue trovas vundeblecojn, devus esti rekompencitaj per premioskemo. La protokolo povas esti plibonigita inkluzivante la identecon de la uzanto en API-transakciojn. Certigu, ke ĉiuj tavoloj de via API-arkitekturo estas reviziitaj per uzado de datumoj de Access Token.
konkludo
Platformarkitektoj povas ekipi siajn sistemojn por teni unu paŝon antaŭ atakantoj sekvante establitajn vundeblecojn kriteriojn. Ĉar API-oj povas disponigi alireblecon al Persone Identeblaj Informoj (PII), konservi la sekurecon de tiaj servoj estas kritika por kaj firmaostabileco kaj konformeco al leĝaro kiel ekzemple GDPR. Neniam sendu OAuth-ĵetonojn rekte per API sen uzi API-Enirejon kaj la Phantom Token Approach.
Antaŭenigita API:
