Ketiadaan semakan keselamatan pada titik akhir koleksi GET membolehkan sesiapa sahaja dengan akaun CoopCycle asas menarik buku alamat lengkap setiap kedai dalam satu instans kongsi, mendedahkan nama, alamat jalan dan poskod pelanggan yang tidak terkira banyaknya. Kelemahan tersebut telah ditampal dalam masa dua hari, dan pengguna digesa untuk menaik taraf ke versi terkini yang dikeluarkan.

Bagaimana kebocoran itu berlaku

CoopCycle – sebuah platform logistik sumber terbuka yang digunakan oleh koperasi penghantaran makanan – mendefinisikan API-nya dengan rangka kerja PHP API Platform. Dalam rangka kerja tersebut, setiap operasi (POST, GET, dll.) mesti dipasangkan dengan ungkapan keselamatan; jika ungkapan tersebut ditinggalkan, rangka kerja akan menjalankan kod tanpa sebarang semakan kebenaran.

Pembangun telah melindungi permintaan POST yang mencipta atau mengemas kini senarai alamat kedai dengan ungkapan standard is_granted('edit', object). Ini berfungsi kerana permintaan tersebut menyasarkan entiti kedai tunggal, memberikan rangka kerja satu "objek" konkrit untuk dinilai.

Permintaan GET yang membaca sumber yang sama menyasarkan satu koleksi: /api/stores/{id}/addresses. Sebuah koleksi tidak mempunyai objek tunggal, jadi ungkapan is_granted('edit', object) yang sama tidak boleh digunakan. Kerana pembangun meninggalkan baris keselamatan tersebut, rangka kerja memberikan data alamat kepada mana-mana pengguna yang disahkan, tanpa mengira tenant.

Pada satu instans CoopCycle yang dikongsi, pengguna berniat jahat boleh sekadar mengulang melalui ID kedai, menghantar permintaan GET ke titik akhir tersebut, dan mengumpul alamat rumah setiap pelanggan yang disimpan dalam sistem. Tiada keistimewaan tambahan diperlukan selain daripada akaun biasa.

Mengapa pepijat itu masih wujud

Masalah ini bukan sekadar kecuaian mudah. Model keselamatan deklaratif API Platform kekurangan cara yang mudah untuk menyatakan "pengguna mesti tergolong dalam tenant yang sama dengan setiap objek dalam koleksi tersebut." Baris kod yang hilang itu berada tepat di tempat di mana rangka kerja menjadikan proses kebenaran (authorization) menjadi rumit.

Memburukkan lagi isu ini, set ujian projek tersebut sebenarnya mengesahkan bahawa respons GET yang mengandungi semua alamat adalah tingkah laku yang dijangkakan. Dalam erti kata lain, ujian automatik lulus kerana fixtures yang digunakan dalam ujian membenarkan akses rentas-tenant, yang secara berkesan menyembunyikan kerentanan tersebut. Set ujian yang menunjukkan status "hijau" dalam kes ini memberikan rasa selamat yang palsu.

Siapa yang menang dan siapa yang kalah

  • Pelanggan: Maklumat pengenalan peribadi (PII) mereka – nama penuh dan alamat rumah – telah terdedah kepada sesiapa sahaja di platform tersebut. Walaupun data tersebut tidak disiarkan secara terbuka, pelanggaran itu telah menjejaskan privasi merentasi pelbagai koperasi.
  • Koperasi yang menggunakan CoopCycle: Kepercayaan terhadap keupayaan platform untuk melindungi data tenant telah tergugat. Mana-mana koperasi yang belum menaik taraf menghadapi risiko pendedahan yang berterusan.
  • Penyelenggara CoopCycle: Tindak balas pantas mereka – tampalan dalam masa dua hari dan penambahan ujian regresi – telah mengehadkan tempoh eksploitasi dan menunjukkan pengurusan sumber terbuka yang bertanggungjawab. Walau bagaimanapun, insiden ini menekankan keperluan untuk proses semakan keselamatan yang lebih ketat, terutamanya di sekeliling tetapan lalai (defaults) yang dipacu oleh rangka kerja.

Apa yang perlu diperhatikan oleh pembangun dan juruaudit

  • Asimetri operasi: Jika satu POST (atau sebarang operasi mutasi) pada sesuatu laluan dilindungi tetapi GET yang sepadan adalah terbuka, percanggahan tersebut adalah tanda amaran. POST mendedahkan niat pembangun untuk melindungi sumber tersebut.
  • Titik akhir koleksi: Apa-apa sahaja yang mengembalikan senarai dan bukannya item tunggal sering kali berada di luar corak keselamatan biasa. Sahkan bahawa semakan kebenaran ditambah secara eksplisit untuk pembacaan pukal.
  • Realisme set ujian: Pastikan fixtures mencerminkan sempadan tenancy yang sebenar. Ujian yang lulus tetapi mengesahkan kebocoran data rentas-tenant adalah tanda amaran, bukannya lampu hijau.

Pembaikan dan langkah seterusnya

Selepas kerentanan tersebut dilaporkan, pasukan teras CoopCycle menambah ungkapan keselamatan yang hilang pada operasi koleksi GET dan memperkenalkan ujian regresi yang menguatkuasakan pengasingan tenant untuk kedua-dua titik akhir item tunggal dan koleksi. Tampalan tersebut dihantar dalam versi perisian yang seterusnya.

Pengguna CoopCycle harus:

  1. Sahkan bahawa mereka menjalankan versi perisian yang terkini.
  2. Semak sebarang sambungan atau pemalam tersuai yang mungkin memperkenalkan jurang tahap koleksi yang serupa.
  3. Jalankan semula imbasan keselamatan dengan fokus pada asimetri baca/tulis merentasi semua laluan API.

Kesimpulan

Kerangka kerja yang menjadikan keselamatan bersifat deklaratif boleh menyembunyikan jurang yang berbahaya apabila pembangun bergantung pada corak yang hanya berfungsi untuk objek tunggal. Satu semakan mudah—adakah bahagian bacaan bagi sesuatu titik akhir mempunyai kawalan yang sama dengan bahagian penulisan?—boleh mendedahkan satu kelas kebocoran rentas-penyewa yang jika tidak, akan terus tersembunyi di sebalik set ujian yang lulus (green test suites).