Kurangnya pemeriksaan keamanan pada endpoint koleksi GET memungkinkan siapa pun dengan akun CoopCycle dasar untuk mengambil seluruh buku alamat dari setiap toko dalam sebuah instansi bersama, sehingga mengekspos nama, alamat jalan, dan kode pos dari pelanggan yang tak terhitung jumlahnya. Celah ini telah diperbaiki dalam waktu dua hari, dan pengguna sangat diimbau untuk memperbarui ke versi terbaru yang telah dirilis.

Bagaimana kebocoran itu terjadi

CoopCycle – sebuah platform logistik sumber terbuka yang digunakan oleh koperasi pengiriman makanan – mendefinisikan API-nya menggunakan framework PHP API Platform. Dalam framework tersebut, setiap operasi (POST, GET, dll.) harus dipasangkan dengan ekspresi keamanan; jika ekspresi tersebut dilewatkan, framework akan menjalankan kode tanpa pemeriksaan otorisasi apa pun.

Para pengembang telah melindungi permintaan POST yang membuat atau memperbarui daftar alamat toko dengan ekspresi standar is_granted('edit', object). Hal ini berhasil karena permintaan tersebut menargetkan satu entitas toko, sehingga memberikan framework sebuah "objek" konkret untuk dievaluasi.

Namun, permintaan GET yang membaca sumber daya yang sama menargetkan sebuah koleksi: /api/stores/{id}/addresses. Sebuah koleksi tidak memiliki satu objek tunggal, sehingga ekspresi is_granted('edit', object) yang sama tidak dapat diterapkan. Karena pengembang melewatkan baris keamanan tersebut, framework menyajikan data alamat kepada pengguna terautentikasi mana pun, tanpa memandang tenant-nya.

Pada instansi CoopCycle yang digunakan bersama, pengguna yang berniat buruk cukup melakukan iterasi melalui ID toko, mengirimkan permintaan GET ke endpoint tersebut, dan mengambil (scrape) alamat rumah dari setiap pelanggan yang tersimpan dalam sistem. Tidak diperlukan hak istimewa tambahan selain akun normal.

Mengapa bug tersebut tetap ada

Masalah ini bukan sekadar kelalaian sederhana. Model keamanan deklaratif milik API Platform kurang memiliki cara yang lugas untuk menyatakan bahwa "pengguna harus termasuk dalam tenant yang sama dengan setiap objek dalam koleksi tersebut." Baris kode yang hilang tersebut berada tepat di tempat di mana framework membuat proses otorisasi menjadi rumit.

Memperburuk masalah, suite pengujian proyek tersebut sebenarnya menyatakan bahwa respons GET yang berisi semua alamat adalah perilaku yang diharapkan. Dengan kata lain, pengujian otomatis lulus karena fixture yang digunakan dalam pengujian mengizinkan akses lintas tenant, yang secara efektif menutupi kerentanan tersebut. Dalam kasus ini, suite pengujian yang "hijau" (lulus) memberikan rasa aman yang palsu.

Siapa yang diuntungkan dan siapa yang dirugikan

  • Pelanggan: Informasi identitas pribadi (PII) mereka – nama lengkap dan alamat rumah – terekspos kepada siapa pun di platform tersebut. Meskipun data tersebut tidak dipublikasikan secara umum, pelanggaran ini mengompromikan privasi di berbagai koperasi.
  • Koperasi yang menggunakan CoopCycle: Kepercayaan terhadap kemampuan platform dalam menjaga data tenant terguncang. Koperasi mana pun yang belum melakukan pembaruan menghadapi risiko paparan data yang berkelanjutan.
  • Pemelihara (maintainer) CoopCycle: Respons cepat mereka – perbaikan dalam dua hari dan penambahan uji regresi – membatasi jendela eksploitasi dan menunjukkan pengelolaan sumber terbuka yang bertanggung jawab. Namun, insiden ini menyoroti perlunya proses peninjauan keamanan yang lebih ketat, terutama di sekitar pengaturan default yang didorong oleh framework.

Apa yang harus diperhatikan oleh pengembang dan auditor

  • Asimetri operasi: Jika sebuah POST (atau operasi mutasi lainnya) pada suatu jalur dilindungi, tetapi GET yang bersesuaian terbuka, ketidaksesuaian tersebut adalah tanda bahaya. POST menunjukkan niat pengembang untuk melindungi sumber daya tersebut.
  • Endpoint koleksi: Apa pun yang mengembalikan daftar alih-alih item tunggal sering kali berada di luar pola keamanan biasa. Pastikan pemeriksaan otorisasi ditambahkan secara eksplisit untuk pembacaan massal (bulk reads).
  • Realisme suite pengujian: Pastikan fixture mencerminkan batasan tenant yang sebenarnya. Pengujian yang lulus tetapi memvalidasi kebocoran data lintas tenant adalah tanda peringatan, bukan lampu hijau.

Perbaikan dan langkah selanjutnya

Setelah kerentanan dilaporkan, tim inti CoopCycle menambahkan ekspresi keamanan yang hilang ke operasi koleksi GET dan memperkenalkan uji regresi yang menegakkan isolasi tenant baik untuk endpoint item tunggal maupun koleksi. Patch tersebut dikirimkan dalam versi perangkat lunak berikutnya.

Pengguna CoopCycle harus:

  1. Memverifikasi bahwa mereka menjalankan versi perangkat lunak terbaru.
  2. Meninjau setiap ekstensi atau plugin kustom yang mungkin menimbulkan celah serupa pada tingkat koleksi.
  3. Menjalankan ulang pemindaian keamanan dengan fokus pada asimetri baca/tulis di semua rute API.

Kesimpulan

Framework yang membuat keamanan bersifat deklaratif dapat menyembunyikan celah berbahaya ketika pengembang mengandalkan pola yang hanya berfungsi untuk objek tunggal. Sebuah pemeriksaan sederhana—apakah sisi pembacaan (read side) dari sebuah endpoint memiliki proteksi (guard) yang sama dengan sisi penulisan (write side)?—dapat mengungkap sekelompok kebocoran lintas-penyewa (cross-tenant leaks) yang jika tidak, akan tetap tersembunyi di balik rangkaian pengujian (test suites) yang lolos (green).