Web Cache Poisoning: Cara Kerja Serangan dan Langkah Pencegahannya

Cache membantu website merespons lebih cepat dan mengurangi beban server dengan menyimpan salinan respons yang bisa digunakan kembali. Namun, konfigurasi cache yang keliru dapat membuka celah keamanan. Salah satunya adalah web cache poisoning, yaitu kondisi ketika penyerang membuat cache menyimpan respons yang tidak semestinya sehingga respons tersebut kemudian diterima oleh pengunjung lain.

Serangan ini tidak selalu membutuhkan akses ke server. Dalam skenario tertentu, penyerang memanfaatkan perbedaan cara aplikasi dan sistem cache menafsirkan permintaan HTTP. Memahami kunci cache, header, dan aturan penyimpanan merupakan langkah penting untuk mencegahnya.

Apa itu web cache poisoning?

Web cache poisoning terjadi ketika penyerang memengaruhi respons yang disimpan oleh cache bersama—misalnya cache reverse proxy, CDN, atau lapisan akselerasi web—lalu membuat cache menyajikan respons yang sudah dimanipulasi kepada permintaan berikutnya. Dampaknya bergantung pada respons yang berhasil diracuni: mulai dari konten salah, tautan berbahaya, pengalihan yang tidak diinginkan, hingga potensi eksekusi skrip di browser jika konteks dan kelemahan lain mendukungnya.

Cache bukan otomatis rentan hanya karena aktif. Risiko biasanya muncul ketika cache menyimpan respons berdasarkan sebagian atribut permintaan, sementara aplikasi menggunakan atribut lain untuk membentuk konten. Perbedaan tersebut membuat dua permintaan yang dianggap setara oleh cache sebenarnya menghasilkan respons yang berbeda dari aplikasi.

Bagaimana serangan dapat terjadi?

Bayangkan sebuah halaman membangun tautan berdasarkan header permintaan tertentu, tetapi header tersebut tidak ikut diperhitungkan dalam cache key. Penyerang mengirim permintaan dengan nilai yang dibuat khusus. Aplikasi menghasilkan respons yang terpengaruh nilai itu, lalu cache menyimpannya di bawah kunci yang juga dipakai pengunjung biasa. Ketika pengunjung lain membuka URL yang sama, cache dapat mengirim respons yang sudah terkontaminasi.

Parameter query, header yang tidak lazim, variasi host, dan perbedaan normalisasi URL dapat menjadi sumber ketidaksesuaian. Namun, tidak setiap header atau parameter bisa dieksploitasi. Penyerang tetap membutuhkan kombinasi perilaku aplikasi dan aturan cache yang membuat respons berbahaya dapat disimpan serta digunakan ulang.

Dampak terhadap website dan pengguna

• Konten yang dimanipulasi: pengunjung melihat informasi atau tautan yang tidak berasal dari konten yang dimaksud pemilik situs.
• Pengalihan yang tidak diinginkan: respons cache dapat mengarahkan pengguna ke alamat lain jika aplikasi dan cache menangani pengalihan secara tidak aman.
• Kerusakan layanan: halaman yang salah dapat terus disajikan sampai entri cache kedaluwarsa atau dihapus.
• Risiko keamanan lanjutan: dalam kondisi tertentu, respons yang diracuni dapat membantu serangan lain, misalnya skrip berbahaya yang dijalankan pada origin website.

Besarnya dampak ditentukan oleh halaman yang terpengaruh, durasi cache, cakupan cache bersama, serta apakah respons membutuhkan autentikasi atau berisi data khusus pengguna.

Langkah pencegahan yang praktis

1. Rancang cache key dengan benar

Tinjau atribut yang benar-benar memengaruhi respons, lalu pastikan atribut tersebut tercakup dalam cache key atau tidak boleh memengaruhi respons yang disimpan bersama. Jangan menambahkan semua header secara membabi buta karena hal itu dapat menurunkan rasio cache. Tujuannya adalah menyamakan asumsi cache dengan perilaku aplikasi.

2. Jangan menyimpan respons yang dipersonalisasi secara sembarangan

Halaman yang memuat informasi akun, token, data pribadi, atau konten khusus pengguna perlu aturan cache yang ketat. Gunakan kebijakan seperti Cache-Control: private atau no-store sesuai kebutuhan, dan jangan mengandalkan cache bersama untuk membedakan pengguna jika mekanismenya tidak dirancang untuk itu.

3. Validasi header dan parameter

Aplikasi sebaiknya tidak membangun URL, HTML, atau pengalihan langsung dari nilai permintaan tanpa validasi. Gunakan daftar nilai yang diizinkan bila memungkinkan, tetapkan host kanonis, dan tolak nilai yang tidak masuk akal. Pengamanan keluaran juga penting: validasi input tidak menggantikan encoding kontekstual saat memasukkan data ke HTML.

4. Uji perilaku cache sebelum perubahan dirilis

Di lingkungan pengujian, bandingkan respons untuk permintaan yang berbeda pada URL yang sama. Periksa header seperti Age, Vary, Cache-Control, dan indikator HIT/MISS yang disediakan CDN. Pastikan variasi yang mengubah isi respons tidak saling berbagi entri cache secara keliru. Lakukan pengujian terkontrol dan hindari menguji payload berbahaya pada sistem produksi tanpa izin.

5. Siapkan pemulihan dan pemantauan

Dokumentasikan cara menghapus entri cache tertentu, menonaktifkan aturan cache bermasalah, dan memulihkan konfigurasi sebelumnya. Pantau lonjakan respons tak terduga, pengalihan yang berubah, serta pola cache HIT yang tidak sesuai. Setelah insiden, periksa konfigurasi aplikasi dan CDN—membersihkan cache saja tidak menghilangkan akar masalah.

Hubungannya dengan CDN dan keamanan web

CDN dapat mempercepat website sekaligus menambahkan lapisan aturan yang perlu ditinjau. Gunakan aturan cache yang sesederhana mungkin, batasi cache untuk jalur yang memang aman, dan pastikan perubahan pada origin tidak membuat asumsi cache menjadi usang. Untuk perlindungan berlapis, tinjau juga kebijakan validasi signature pada webhook bila website memproses permintaan dari layanan eksternal, serta panduan Core Web Vitals untuk memahami optimasi performa tanpa mengabaikan keamanan.

Kesimpulan

Web cache poisoning memanfaatkan ketidaksesuaian antara cara aplikasi menghasilkan respons dan cara cache menyimpan serta menggunakannya kembali. Pencegahan terbaik dimulai dari cache key yang tepat, aturan ketat untuk konten personal, validasi nilai permintaan, dan pengujian variasi respons secara berkala.

Checklist audit konfigurasi cache

Saat meninjau konfigurasi, buat inventaris jalur yang boleh di-cache dan tandai halaman yang memuat data akun atau respons personal. Untuk setiap aturan, catat cache key, TTL, header yang memengaruhi variasi respons, serta pihak yang bertanggung jawab. Uji dari kondisi cache kosong dan cache terisi, karena respons pertama dan permintaan berikutnya dapat menunjukkan perilaku berbeda.

Periksa pula apakah parameter pelacakan yang tidak memengaruhi konten perlu dinormalisasi, dan pastikan aturan purge dapat dijalankan saat terjadi insiden. Simpan hasil pengujian sebagai bagian dari proses perubahan konfigurasi agar regresi lebih mudah diketahui.

Cache yang dikonfigurasi dengan benar dapat tetap memberi manfaat performa tanpa menjadikan kecepatan sebagai celah keamanan.