🚀 Race Condition Seru: Ngebobol Limit Cuma Modal Request Paralel

Arjuna AryaArjuna Arya
2 min read

\> Cerita gue nemu bug yang ngizinin user bikin resource lebih dari limit yang harusnya dibatesin — dan ya, semua ini cuma karena backend nggak siap diajak balapan 😄

## 📌 Intro Dulu

Jadi, gue nemu celah race condition di sebuah platform yang ngasih user free-tier cuma bisa bikin maksimal 3 workbook.

Nah, dengan sedikit trik concurrency dan tools yang tepat, ternyata gue bisa bikin lebih dari 3, bahkan sampe 6 workbook, dan itu semua di akun gratis.

Gokil? Lumayan. Bisa jadi abuse? Banget.

## 🎯 Gimana Sistemnya Jalan?

Fitur utamanya: user gratis cuma boleh bikin maksimal 3 workbook.

Di UI ditulis jelas kayak:
\> “You’re using 0 of 3 workbooks”

Backend-nya? Hmm… Ternyata dia gak terlalu tegas kalau lagi dibanjirin request barengan 😏

## 🧨 Celahnya Dimana?

Race condition ini muncul karena:
- Sistem cuma ngecek “udah 3 workbook belum?” pas request masuk
- Tapi dia nggak nge-lock proses itu, jadi kalo 10 request dikirim barengan, semua ngira masih di bawah limit

Akhirnya, limit-nya bisa dibobol barengan sebelum sistem sadar.

## 🧪 Langkah Reproduksi

Gampang, tinggal ikutin ini:

1.Login ke akun free-tier
2. Pastikan workbook masih kosong (misal 0 dari 3)
3. Intercept request

POST /api/workbook/create

4. Pake tool kayak Turbo Intruder, Python script pake threading, atau Burp Intruder buat spam 10 request barengan
5. Liat hasilnya: bisa lebih dari 3 workbook ke-create. Gue dapet 6 waktu itu 💥

## 🎯 Dampaknya Apa?

  • Bypass Fitur Premium: User gratis bisa manfaatin fitur seharusnya berbayar
    - Abuse Resource: Bisa spam workbook sebanyak-banyaknya
    - Skalabilitas Masalah: Kalau banyak user abuse barengan, bisa bikin server ngap-ngapan
    - Potential Chaining: Bisa digabung sama bug lain buat privilege escalation, dll

## 🛡️ Saran Mitigasi

Buat tim dev, solusi ideal buat cegah ini:

- Gunain atomic operations atau database transaction
- Terapin locking di sisi backend saat proses validasi kuota
- Implementasi rate limit atau mutex per user untuk endpoint sensitif
- Jangan andalkan validasi di frontend aja (karena bisa dibypass dengan mudah)

## 📝 Penutup

Celah race condition kayak gini seringkali luput karena:
- Butuh timing yang pas buat triggered
- Gak keliatan jelas di UI
- Tapi punya impact lumayan serius

Makanya penting banget buat cek proses critical di backend, terutama yang menyangkut kuota, transaksi, atau hak akses.

Disclaimer: Bug ini udah gue laporin ke pihak terkait lewat program resmi. Nama platform & domain gue samarin dulu sampe issue dinyatakan fix.

0
Subscribe to my newsletter

Read articles from Arjuna Arya directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Arjuna Arya
Arjuna Arya