Ukosefu wa ukaguzi wa usalama kwenye mwisho wa mkusanyiko (collection endpoint) wa GET uliruhusu mtu yeyote mwenye akaunti ya kawaida ya CoopCycle kupata kitabu kamili cha anwani za kila duka katika mfumo wa pamoja (shared instance), na kufichua majina, anwani za mitaa, na nambari za posta za wateja wengi sana. Hitilafu hiyo ilirekebishwa ndani ya siku mbili, na watumiaji wanahimizwa kuhuisha (upgrade) hadi toleo la hivi karibuni lililotolewa.

Jinsi uvujaji ulivyotokea

CoopCycle – jukwaa la vifaa (logistics) la chanzo huru linalotumiwa na ushirika wa usambazaji chakula – hufafanua API yake kwa kutumia mfumo wa PHP unaoitwa API Platform. Katika mfumo huo, kila operesheni (POST, GET, n.k.) lazima iambatane na usemi wa usalama (security expression); ikiwa usemi huo utapuuzwa, mfumo huo huendesha kodi bila ukaguzi wowote wa idhini.

Watengenezaji walilinda ombi la POST linalounda au kuhuisha orodha ya anwani ya duka kwa kutumia usemi wa kawaida wa is_granted('edit', object). Hilo linafanya kazi kwa sababu ombi hilo linalenga kitu kimoja cha duka (single store entity), likitoa "object" madhubuti kwa mfumo huo ili kuifanyia tathmini.

Ombi la GET linalosoma rasilimali hiyo hiyo linalenga mkusanyiko (collection): /api/stores/{id}/addresses. Mkusanyiko hauna "object" moja, hivyo usemi ule ule wa is_granted('edit', object) hauwezi kutumika. Kwa sababu watengenezaji walisahau mstari wa usalama, mfumo huo ulitoa data za anwani kwa mtumiaji yeyote aliyethibitishwa, bila kujali umiliki wa data (tenancy).

Katika mfumo wa pamoja wa CoopCycle, mtumiaji mwenye nia mbaya angeweza tu kupitia ID za maduka, kutoa maombi ya GET kwenye mwisho huo, na kuchukua anwani za nyumbani za kila mteja aliyehifadhiwa kwenye mfumo. Hakukuwa na haja ya mamlaka ya ziada zaidi ya akaunti ya kawaida.

Kwa nini hitilafu hiyo ilidumu

Tatizo hilo halikuwa kosa la kawaida tu. Mfumo wa usalama wa API Platform (declarative security model) hauna njia rahisi ya kueleza kuwa "mtumiaji lazima awe katika umiliki uleule (tenant) kama kila object katika mkusanyiko." Mstari wa kodi uliokosekana ulikuwa pale pale ambapo mfumo huo ulifanya idhini kuwa ngumu.

Kikiongezea tatizo hilo, seti ya majaribio (test suite) ya mradi huo ilithibitisha kuwa jibu la GET lenye anwani zote lilikuwa tabia inayotarajiwa. Kwa maneno mengine, majaribio ya kiotomatiki yalifanikiwa kwa sababu "fixtures" zilizotumiwa kwenye majaribio ziliruhusu ufikiaji wa kuvuka umiliki (cross-tenant access), jambo lililoficha udhaifu huo. Seti ya majaribio iliyoonyesha rangi ya kijani, katika hali hii, ilitoa hisia ya uongo ya usalama.

Nani anafaidika na nani anapata hasara

  • Wateja: Taarifa zao binafsi (PII) – majina kamili na anwani za nyumbani – zilifichuliwa kwa mtu yeyote kwenye jukwaa hilo. Ingawa data haikuchapishwa hadharani, uvujaji huo ulihatarisha faragha katika ushirika nyingi.
  • Ushirika zinazotumia CoopCycle: Imani katika uwezo wa jukwaa la kulinda data za umiliki (tenant data) ilitikiswa. Ushirika wowote ambao bado haujahuisha (upgrade) ulikabiliwa na hatari ya kuendelea kufichuliwa.
  • Wadhibiti wa CoopCycle: Majibu yao ya haraka – marekebisho (patch) ndani ya siku mbili na kuongezwa kwa majaribio ya kurejesha (regression tests) – yalipunguza muda wa unyonyaji na kuonyesha usimamizi wa kuwajibika wa chanzo huru. Hata hivyo, tukio hili linaangazia hitaji la michakato ya ukaguzi wa usalama iliyokazwa zaidi, hasa kuhusu mipangilio ya awali (defaults) inayodhibitiwa na mfumo.

Yale ambayo watengenezaji na wakaguzi wanapaswa kuyatafuta

  • Asymmetry ya operesheni: Ikiwa POST (au operesheni yoyote inayobadilisha data) kwenye njia fulani inalindwa lakini GET inayolingana nayo iko wazi, utofauti huo ni ishara ya hatari. POST inaonyesha nia ya watengenezaji kulinda rasilimali hiyo.
  • Mwisho wa mkusanyiko (Collection endpoints): Chochote kinachorudisha orodha badala ya kitu kimoja mara nyingi hukosa mifumo ya kawaida ya usalama. Hakikisha kuwa ukaguzi wa idhini umeongezwa wazi kwa ajili ya kusoma data kwa wingi.
  • Uhalisia wa seti ya majaribio: Hakikisha "fixtures" zinaakisi mipaka halisi ya umiliki (tenancy boundaries). Jaribio linalofanikiwa lakini linathibitisha uvujaji wa data wa kuvuka umiliki ni ishara ya onyo, si ruhusa ya kuendelea.

Marekebisho na hatua zinazofuata

Baada ya udhaifu huo kuripotiwa, timu kuu ya CoopCycle iliongeza usemi wa usalama uliokosekana kwenye operesheni ya mkusanyiko wa GET na kuanzisha majaribio ya kurejesha (regression tests) yanayolazimisha utengano wa umiliki (tenant isolation) kwa mwisho wa kitu kimoja na wa mkusanyiko. Marekebisho hayo yalipatikana katika toleo linalofuata la programu hiyo.

Watumiaji wa CoopCycle wanapaswa:

  1. Kuhakikisha kuwa wanatumia toleo la hivi karibuni la programu hiyo.
  2. Kupitia nyongeza (extensions) au programu nyongeza (plugins) zozote za kipekee ambazo zinaweza kuleta mapengo kama hayo katika kiwango cha mkusanyiko.
  3. Kurudia ukaguzi wa usalama kwa kuzingatia kutofautiana kwa kusoma/kuandika (read/write asymmetries) katika njia zote za API.

Hitimisho

Mifumo inayofanya usalama kuwa wa kueleza (declarative) inaweza kuficha mapengo hatari wakati watengenezaji wanapotegemea mifumo inayofanya kazi kwa vitu moja moja pekee. Ukaguzi rahisi—je, upande wa kusoma wa endpoint una ulinzi uleule kama upande wa kuandika?—unaweza kufichua aina ya uvujaji wa data kati ya watumiaji (cross-tenant leaks) ambayo vinginevyo ingebaki imefichika nyuma ya majaribio yenye mafanikio (green test suites).