Nangungunang OATH API Vulnerabilities
Nangungunang OATH API Vulnerabilities: Intro
Pagdating sa mga pagsasamantala, ang mga API ang pinakamagandang lugar upang magsimula. API ang pag-access ay karaniwang binubuo ng tatlong bahagi. Ang mga kliyente ay binibigyan ng mga token ng isang Authorization Server, na tumatakbo sa tabi ng mga API. Tumatanggap ang API ng mga token ng access mula sa kliyente at inilalapat ang mga panuntunan sa awtorisasyon na partikular sa domain batay sa mga ito.
Ang mga modernong software application ay mahina sa iba't ibang panganib. Panatilihin upang mapabilis ang pinakabagong mga pagsasamantala at mga bahid sa seguridad; Ang pagkakaroon ng mga benchmark para sa mga kahinaang ito ay mahalaga upang matiyak ang seguridad ng application bago mangyari ang isang pag-atake. Ang mga third-party na application ay lalong umaasa sa OAuth protocol. Ang mga user ay magkakaroon ng mas mahusay na pangkalahatang karanasan ng user, pati na rin ang mas mabilis na pag-log in at pahintulot, salamat sa teknolohiyang ito. Maaaring mas secure ito kaysa sa kumbensyonal na awtorisasyon dahil hindi kailangang ibunyag ng mga user ang kanilang mga kredensyal sa third-party na application upang ma-access ang isang ibinigay na mapagkukunan. Bagama't ang protocol mismo ay ligtas at secure, ang paraan ng pagpapatupad nito ay maaaring magbigay sa iyo ng bukas na pag-atake.
Kapag nagdidisenyo at nagho-host ng mga API, nakatuon ang artikulong ito sa mga karaniwang kahinaan ng OAuth, pati na rin sa iba't ibang mga pagpapagaan sa seguridad.
Sirang Object Level Authorization
Mayroong malawak na pag-atake kung nilabag ang pahintulot dahil ang mga API ay nagbibigay ng access sa mga bagay. Dahil dapat ma-authenticate ang mga item na naa-access sa API, kinakailangan ito. Magpatupad ng mga pagsusuri sa awtorisasyon sa antas ng object gamit ang API gateway. Tanging ang mga may naaangkop na mga kredensyal ng pahintulot ang dapat payagang ma-access.
Sirang User Authentication
Ang mga hindi awtorisadong token ay isa pang madalas na paraan para makakuha ng access ang mga umaatake sa mga API. Maaaring ma-hack ang mga system ng pagpapatotoo, o maaaring ma-expose nang mali ang isang API key. Maaaring ang mga token ng pagpapatunay ginagamit ng mga hacker para makakuha ng access. I-authenticate lang ang mga tao kung mapagkakatiwalaan sila, at gumamit ng malalakas na password. Sa OAuth, maaari kang lumampas sa mga API key lamang at makakuha ng access sa iyong data. Dapat mong palaging isipin kung paano ka papasok at lalabas sa isang lugar. Ang OAuth MTLS Sender Constrained Token ay maaaring gamitin kasabay ng Mutual TLS upang magarantiya na ang mga kliyente ay hindi gagawa ng masama at magpasa ng mga token sa maling partido habang ina-access ang iba pang mga machine.
Pag-promote ng API:
Sobrang Exposure ng Data
Walang mga hadlang sa bilang ng mga endpoint na maaaring ma-publish. Kadalasan, hindi lahat ng feature ay available sa lahat ng user. Sa pamamagitan ng paglalantad ng higit pang data kaysa sa talagang kinakailangan, inilalagay mo sa panganib ang iyong sarili at ang iba. Iwasan ang pagsisiwalat ng sensitibo impormasyon hanggang sa ito ay ganap na kinakailangan. Maaaring tukuyin ng mga developer kung sino ang may access sa kung ano sa pamamagitan ng paggamit ng Mga Saklaw at Claim ng OAuth. Maaaring tukuyin ng mga claim kung aling mga seksyon ng data ang may access ang isang user. Ang kontrol sa pag-access ay maaaring gawing mas simple at mas madaling pamahalaan sa pamamagitan ng paggamit ng isang karaniwang istraktura sa lahat ng mga API.
Kakulangan ng Mga Mapagkukunan at Paglilimita sa Rate
Ang mga black hat ay kadalasang gumagamit ng denial-of-service (DoS) assaults bilang isang brute-force na paraan ng pag-overwhelm sa isang server at kaya binabawasan ang uptime nito sa zero. Nang walang mga paghihigpit sa mga mapagkukunang maaaring tawagin, ang isang API ay mahina sa isang nakakapanghina na pag-atake. 'Gamit ang API gateway o tool sa pamamahala, maaari kang magtakda ng mga paghihigpit sa rate para sa mga API. Dapat isama ang pag-filter at pagination, pati na rin ang mga sagot na pinaghihigpitan.
Maling configuration ng Security System
Ang iba't ibang mga alituntunin sa pagsasaayos ng seguridad ay medyo komprehensibo, dahil sa malaking posibilidad ng maling configuration ng seguridad. Ang ilang maliliit na bagay ay maaaring mapahamak ang seguridad ng iyong platform. Posibleng ang mga itim na sumbrero na may lihim na layunin ay maaaring makatuklas ng sensitibong impormasyong ipinadala bilang tugon sa mga maling nabuong query, bilang halimbawa.
Pagtatalaga sa Misa
Dahil lamang sa isang endpoint ay hindi tinukoy sa publiko ay hindi nagpapahiwatig na hindi ito maa-access ng mga developer. Ang isang lihim na API ay maaaring madaling maharang at reverse-engineered ng mga hacker. Tingnan ang pangunahing halimbawang ito, na gumagamit ng bukas na Bearer Token sa isang "pribadong" API. Sa kabilang banda, maaaring umiral ang pampublikong dokumentasyon para sa isang bagay na eksklusibo para sa personal na paggamit. Ang nakalantad na impormasyon ay maaaring gamitin ng mga itim na sumbrero upang hindi lamang basahin kundi manipulahin din ang mga katangian ng bagay. Isaalang-alang ang iyong sarili na isang hacker habang naghahanap ka ng mga potensyal na kahinaan sa iyong mga depensa. Payagan lamang ang mga may wastong karapatan na ma-access ang ibinalik. Para mabawasan ang kahinaan, limitahan ang API response package. Ang mga sumasagot ay hindi dapat magdagdag ng anumang mga link na hindi lubos na kinakailangan.
Na-promote na API:
Hindi wastong pamamahala ng asset
Bukod sa pagpapahusay ng produktibidad ng developer, ang mga kasalukuyang bersyon at dokumentasyon ay mahalaga para sa iyong sariling kaligtasan. Maghanda para sa pagpapakilala ng mga bagong bersyon at ang paghinto sa paggamit ng mga lumang API nang maaga. Gumamit ng mas bagong mga API sa halip na payagan ang mga nakatatanda na manatiling ginagamit. Maaaring gamitin ang Detalye ng API bilang pangunahing pinagmumulan ng katotohanan para sa dokumentasyon.
Iniksyon
Ang mga API ay mahina sa iniksyon, ngunit gayundin ang mga third-party na developer na app. Maaaring gamitin ang malisyosong code upang magtanggal ng data o magnakaw ng kumpidensyal na impormasyon, gaya ng mga password at numero ng credit card. Ang pinakamahalagang aral na dapat alisin dito ay ang huwag umasa sa mga default na setting. Ang iyong pamamahala o tagatustos ng gateway ay dapat na matugunan ang iyong mga natatanging pangangailangan sa aplikasyon. Ang mga mensahe ng error ay hindi dapat magsama ng sensitibong impormasyon. Para maiwasan ang pagtagas ng data ng pagkakakilanlan sa labas ng system, dapat gamitin ang Pairwise Pseudonym sa mga token. Tinitiyak nito na walang kliyente ang maaaring magtulungan upang makilala ang isang user.
Hindi Sapat na Pag-log At Pagsubaybay
Kapag naganap ang isang pag-atake, ang mga koponan ay nangangailangan ng isang mahusay na pinag-isipang diskarte sa reaksyon. Patuloy na sasamantalahin ng mga developer ang mga kahinaan nang hindi nahuhuli kung walang magagamit na maaasahang sistema ng pag-log at pagsubaybay, na magpapataas ng mga pagkalugi at makakasira sa pang-unawa ng publiko sa kumpanya. Magpatibay ng mahigpit na pagsubaybay sa API at diskarte sa pagsubok sa endpoint ng produksyon. Ang mga white hat tester na maagang nakahanap ng mga kahinaan ay dapat na gantimpalaan ng bounty scheme. Maaaring mapabuti ang log trail sa pamamagitan ng pagsasama ng pagkakakilanlan ng user sa mga transaksyon sa API. Tiyakin na ang lahat ng mga layer ng iyong arkitektura ng API ay na-audit sa pamamagitan ng paggamit ng data ng Access Token.
Konklusyon
Ang mga arkitekto ng platform ay maaaring magbigay ng kasangkapan sa kanilang mga system upang manatiling isang hakbang sa unahan ng mga umaatake sa pamamagitan ng pagsunod sa itinatag na pamantayan sa kahinaan. Dahil ang mga API ay maaaring magbigay ng accessibility sa Personally Identifiable Information (PII), ang pagpapanatili ng seguridad ng mga naturang serbisyo ay mahalaga para sa parehong katatagan ng kumpanya at pagsunod sa batas gaya ng GDPR. Huwag magpadala ng mga OAuth token nang direkta sa isang API nang hindi gumagamit ng API Gateway at ang Phantom Token Approach.
Na-promote na API:
