Usalama wa OAuth: Mwongozo kwa Wafanyikazi wa Programu

OAuth 2.0 ndiyo kiwango cha tasnia cha uidhinishaji mbadala. Inaruhusu programu za wahusika wengine kupata rasilimali zilizodhibitiwa kwa niaba ya mtumiaji bila kufichua sifa zao. Walakini, kutekeleza OAuth salama ni ngumu. Mwongozo huu hutoa uchunguzi wa kina wa mazoea bora ya usalama wa OAuth kwa wasanidi programu, ukifunika udhaifu wa kawaida na mikakati ya kupunguza.

Ujumbe Mkuu 1 Usalama wa OAuth sio tu juu ya mtoa OAuth; ni jukumu la pamoja kati ya mtoa, programu ya mteja, na seva ya rasilimali.

Ujumbe Mkuu 2 Uthibitishaji sahihi wa URIs za mwelekezo ni muhimu kuzuia mashambulizi ya kukatiza nambari ya uidhinishaji.

Ujumbe Mkuu 3 Kutumia tokeni fupi za ufikiaji na mzunguko wa tokeni za kufurahisha hupunguza sana athari za ukiukwaji wa tokeni.

Ujumbe Mkuu 4 Kukagua mara kwa mara utekelezaji wako wa OAuth na kusasisha mazoea bora ya usalama ni muhimu.

Kuelewa Mchakato wa OAuth na Udhaifu

OAuth 2.0 hufafanua aina kadhaa za ruzuku, kila moja inafaa kwa matukio tofauti ya programu. Ya kawaida ni:

• Ruzuku ya Nambari ya Uidhinishaji: Inatumika kwa programu za wavuti na simu ambapo mteja anaweza kuhifadhi kwa usalama siri ya mteja.
• Ruzuku Implied: (Imeachwa) Inatumika kwa programu za ukurasa mmoja (SPAs) lakini ni chini ya usalama kwa sababu ya kufichuliwa kwa tokeni za ufikiaji kwenye URL.
• Ruzuku ya Sifa za Nenosiri la Mmiliki wa Rasilimali: (Haishauriwi) Inahitaji mteja kukusanya jina la mtumiaji na nenosiri la mtumiaji, ambayo ni hatari ya usalama.
• Ruzuku ya Sifa za Mteja: Inatumika kwa uthibitishaji wa mashine-kwa-mashine ambapo hakuna muktadha wa mtumiaji.

Udhaifu kadhaa unaweza kutokea wakati wa mchakato wa OAuth:

• Kukatiza Nambari ya Uidhinishaji: Washambuliaji huongoza watumiaji kwenye tovuti mbaya ambayo inaonekana kama seva ya uidhinishaji, wakiiba nambari ya uidhinishaji.
• Umanipulation wa URI ya Mwelekezo: Kuchukua faida ya URIs za mwelekezo zilizokosewa ili kutuma nambari za uidhinishaji kwa seva zilizodhibitiwa na mshambuliaji.
• Ughalifu wa Ombi la Msalaba (CSRF): Washambuliaji huwadanganya watumiaji kuidhinisha programu mbaya.
• Wizi wa Tokeni: Kukiuka tokeni za ufikiaji au tokeni za kufurahisha kupitia udhaifu wa uhifadhi au kukatizwa kwa mtandao.
• Uchaji wa Mteja: Washambuliaji wanatumia kitambulisho cha mteja kilichovunjwa na siri ya kufikia rasilimali.

Kulinda Utekelezaji Wako wa OAuth

Kupunguza udhaifu huu kunahitaji mbinu yenye tabaka nyingi:

1. Uthibitishaji wa URI ya Mwelekezo

Thibitisha kwa ukali URIs za mwelekezo. Ruhusu tu URIs za mwelekezo zilizosajiliwa hapo awali na zilizofafanuliwa wazi. Tekeleza mbinu ya orodha nyeupe na epuka mwelekeo wa wildcard. Hakikisha kwamba mpango wa URI ya mwelekezo (http vs. https) pia umethibitishwa. OAuth 2.0 RFC 6749 sehemu 3.1.2 inaonyesha umuhimu wa uthibitishaji wa URI ya mwelekezo.

2. Parameter ya Hali na Nonce

Tumia parameter ya state kuzuia mashambulizi ya CSRF. Toa thamani ya state ya nasibu ya cryptographic kabla ya kuelekeza kwenye seva ya uidhinishaji na uithibitishe uponapopata kurudisha. Fikiria pia kutumia parameter ya nonce kwa usalama wa ziada.

3. PKCE (Uthibitisho wa Ufunguo kwa Ubadilishanaji wa Nambari)

Tekeleza PKCE, hasa kwa wateja wa umma (kwa mfano, programu za simu, SPAs) ambazo haziwezi kuhifadhi kwa usalama siri ya mteja. PKCE huongeza safu ya ziada ya ulinzi kwa kuhakikisha kuwa programu tu iliyoanzisha ombi la uidhinishaji inaweza kubadilisha nambari ya uidhinishaji kwa tokeni ya ufikiaji.

// Mfano wa msimbo wa PKCE (urahisishwa)
// Toa msimbo mtaalam
let codeVerifier = generateRandomString();
// Toa changamoto ya msimbo kutoka kwa msimbo mtaalam
let codeChallenge = generateCodeChallenge(codeVerifier);
// Jumuisha codeChallenge na codeChallengeMethod katika ombi la uidhinishaji
// ...
// Badilisha nambari ya uidhinishaji kwa tokeni ya ufikiaji, ukitoa msimbo mtaalam
// ...

4. Usimamizi wa Tokeni

Tumia tokeni fupi za ufikiaji kupunguza athari ya ukiukwaji wa tokeni. Tekeleza mzunguko wa tokeni za kufurahisha, ambapo tokeni mpya ya kufurahisha hutolewa na kila usafirishaji wa tokeni ya ufikiaji, ikibatilisha tokeni ya zamani ya kufurahisha. Hifadhi tokeni kwa usalama kwa kutumia usimbaji na udhibiti wa ufikiaji. Kamwe usihifadhi tokeni katika msimbo wa mteja.

Mazingatio ya Usalama wa API

Kulinda mwisho wa API yako ni muhimu sana kama kulinda mchakato wa OAuth. Tekeleza mazoea bora haya:

• Uthibitishaji wa Tokeni: Thibitisha kwa ukamilifu tokeni za ufikiaji kabla ya kuruhusu ufikiaji wa rasilimali. Thibitisha saini ya tokeni, wakati wa kumalizika, na hadhira (dai la aud).
• Uthibitishaji wa Upeo: Tumia vizuizi vya upeo. Hakikisha kwamba tokeni ya ufikiaji ina upeo unaohitajika wa kufikia rasilimali iliyoombwa.
• Ukomo wa Kiwango: Tekeleza ukomo wa kiwango ili kuzuia matumizi mabaya na mashambulizi ya kukataa huduma.
• Uthibitishaji wa Ingizo: Thibitisha pembezo zote za API ili kuzuia mashambulizi ya sindano.
• HTTPS Tu: Toza HTTPS kwa mawasiliano yote ya API.

Jinsi Didit Inavyosaidia

Didit hutoa uwezo wa nguvu wa uthibitishaji wa utambulisho na tathmini ya hatari ambayo inakamilisha usalama wa OAuth. Kwa kuunganisha Didit kwenye mchakato wako wa OAuth, unaweza:

• Thibitisha utambulisho wa mtumiaji kabla ya kutoa tokeni za ufikiaji.
• Gundua shughuli za udanganyifu na kuzuia ufikiaji usioidhinishwa.
• Boresha usalama wa API na udhibiti wa ufikiaji unaotegemea hatari.
• Zingatia mahitaji ya udhibiti yanayohusiana na uthibitishaji wa utambulisho na AML.

Moduli ya Uchunguzi wa AML ya Didit inaweza kuunganishwa ili kuangalia watumiaji dhidi ya orodha za ulimwengu wakati wa mchakato wa OAuth, ikiongeza safu ya ziada ya usalama.

Tayari Kuanza?

Kutekeleza usalama thabiti wa OAuth ni muhimu kwa kulinda programu yako na data ya mtumiaji. Kwa kufuata mazoea bora yaliyobainishwa katika mwongozo huu, unaweza kupunguza sana hatari ya udhaifu unaohusiana na OAuth.

Rasilimali:

• Bei ya Didit
• Hati za Didit
• OAuth 2.0 RFC 6749