Web cache membantu website memberikan respons lebih cepat dengan menyimpan salinan respons yang sering diminta. Namun, konfigurasi cache yang tidak tepat dapat menciptakan celah keamanan yang dikenal sebagai Cache Poisoning via Unkeyed Inputs.
Masalah ini muncul ketika aplikasi memproses input tertentu, tetapi cache tidak memasukkan input tersebut ke dalam cache key. Akibatnya, respons berbahaya dapat tersimpan dan kemudian diberikan kepada pengguna lain yang mengakses resource dengan cache key yang sama.
Karena satu respons dapat digunakan oleh banyak pengguna, dampaknya bisa lebih luas dibandingkan serangan yang hanya memengaruhi satu request.
Apa Itu Cache Poisoning via Unkeyed Inputs?
Cache Poisoning via Unkeyed Inputs adalah teknik serangan yang memanfaatkan input HTTP yang diproses oleh aplikasi tetapi tidak diperhitungkan oleh sistem cache saat menentukan cache key.
Cache biasanya menggunakan beberapa bagian request untuk menentukan apakah dua request dianggap sama. Komponen seperti URL, method, dan Host dapat menjadi bagian dari cache key, sedangkan header atau parameter tertentu mungkin tidak ikut diperhitungkan.
PortSwigger menjelaskan bahwa komponen request yang tidak dimasukkan ke dalam cache key disebut unkeyed components. Jika input tersebut dapat memengaruhi respons yang kemudian disimpan oleh cache, penyerang berpotensi melakukan web cache poisoning (dikutip dari: PortSwigger – Web Cache Poisoning).
Bayangkan sebuah aplikasi menggunakan header tertentu untuk menghasilkan bagian dari halaman. Namun, cache tidak memasukkan header tersebut ke dalam cache key.
Dalam kondisi seperti ini, dua request dengan cache key yang sama dapat menghasilkan respons berbeda di sisi aplikasi. Jika respons yang sudah dimanipulasi kemudian disimpan oleh cache, pengguna lain dapat menerima respons tersebut.
Dengan demikian, masalah utamanya bukan hanya pada input yang tidak tervalidasi. Perbedaan cara aplikasi dan cache memperlakukan input juga menjadi faktor penting.
Bagaimana Cache Poisoning Terjadi?
Serangan biasanya bergantung pada tiga kondisi utama:
Terdapat input yang tidak masuk cache key.
Input tersebut dapat memengaruhi respons aplikasi.
Respons yang dihasilkan dapat disimpan oleh cache.
Jika ketiga kondisi tersebut terpenuhi, respons yang telah dipengaruhi oleh input berbahaya berpotensi menjadi bagian dari cache.
PortSwigger menjelaskan bahwa proses web cache poisoning umumnya melibatkan identifikasi unkeyed input, menghasilkan respons yang berbahaya, lalu memastikan respons tersebut berhasil disimpan oleh cache (dikutip dari: PortSwigger Research – Practical Web Cache Poisoning).
Contoh Unkeyed Inputs
Beberapa input yang dapat menjadi perhatian dalam pengujian keamanan antara lain:
HTTP headers tertentu.
Cookie tertentu.
Query parameter yang dikecualikan dari cache key.
Informasi host atau forwarding header.
Input yang mengalami normalisasi berbeda antara cache dan backend.
Contohnya, header seperti X-Forwarded-Host dapat memengaruhi bagaimana aplikasi menghasilkan URL. Jika header tersebut tidak menjadi bagian dari cache key dan responsnya dapat di-cache, konfigurasi tersebut perlu diperiksa lebih lanjut.
Dampak Cache Poisoning
Dampak serangan sangat bergantung pada bagaimana aplikasi menggunakan unkeyed input tersebut.
Cross-Site Scripting
Jika input berbahaya dapat masuk ke respons HTML tanpa sanitasi yang tepat, cache poisoning dapat digunakan untuk memperbesar dampak XSS.
Alih-alih payload hanya muncul pada request tertentu, respons yang sudah terkontaminasi dapat diberikan kepada pengguna lain melalui cache.
Open Redirect
Input tertentu dapat digunakan untuk memengaruhi URL tujuan. Jika respons tersebut kemudian di-cache, pengguna lain dapat diarahkan ke lokasi yang tidak diharapkan.
Content Manipulation
Cache poisoning juga dapat menyebabkan konten halaman berubah. Dalam kasus tertentu, pengguna dapat melihat informasi yang telah dimodifikasi tanpa menyadari bahwa respons berasal dari cache.
Denial of Service
Jika respons yang tidak valid berhasil disimpan pada cache, pengguna dapat terus menerima respons tersebut sampai entry kedaluwarsa atau dihapus.
Karena cache dapat digunakan oleh banyak pengguna sekaligus, satu kesalahan konfigurasi berpotensi memiliki dampak yang cukup luas.
Merupakan komponen penting dalam memahami serangan ini. Cache menggunakan key tersebut untuk menentukan apakah sebuah request dapat menggunakan respons yang sudah tersimpan.
Masalah muncul ketika aplikasi mempertimbangkan suatu input, tetapi cache mengabaikannya. Perbedaan tersebut dapat menyebabkan cache key collision, yaitu beberapa request berbeda dianggap sebagai request yang sama oleh cache.
Situasi tersebut menjadi berbahaya ketika perbedaan input dapat menghasilkan respons yang berbeda di backend.
Cara Mencegah Cache Poisoning via Unkeyed Inputs
Pencegahan sebaiknya dilakukan pada konfigurasi cache dan aplikasi secara bersamaan.
1. Audit Cache Key
Identifikasi komponen request yang benar-benar digunakan untuk membentuk cache key. Pastikan input yang dapat memengaruhi respons tidak diabaikan secara tidak sengaja.
2. Hindari Input yang Tidak Diperlukan
Jika aplikasi tidak membutuhkan header atau parameter tertentu, sebaiknya jangan menjadikannya sumber data untuk menghasilkan respons.
Pendekatan ini mengurangi jumlah input yang dapat dimanfaatkan untuk memengaruhi konten yang di-cache.
3. Masukkan Input Penting ke Cache Key
Jika sebuah input memang diperlukan dan memengaruhi respons, pertimbangkan untuk memasukkannya ke dalam cache key.
PortSwigger juga merekomendasikan agar input yang diperlukan untuk menghasilkan variasi respons diperhitungkan dalam cache key. Dalam beberapa sistem, mekanisme seperti Vary dapat digunakan untuk membantu menentukan variasi cache berdasarkan header tertentu.
4. Nonaktifkan Cache untuk Respons Sensitif
Tidak semua respons harus di-cache. Halaman yang berisi data personal, informasi autentikasi, atau konten yang sangat dinamis sebaiknya mendapatkan kebijakan caching yang ketat.
5. Validasi Input di Backend
Input dari header, cookie, maupun parameter URL tetap harus divalidasi dan diproses secara aman.
Validasi menjadi semakin penting jika input tersebut digunakan untuk membuat HTML, URL, redirect, atau konten dinamis.
Cache Poisoning vs Cache Deception
Cache Poisoning dan Cache Deception sering dianggap sama, padahal keduanya berbeda.
Pada cache poisoning, penyerang berusaha membuat respons berbahaya tersimpan di cache sehingga dapat diberikan kepada pengguna lain.
Sementara itu, cache deception memanfaatkan perbedaan interpretasi antara cache dan server untuk membuat konten yang seharusnya tidak di-cache diperlakukan seperti resource yang dapat di-cache.
Karena mekanismenya berbeda, strategi mitigasinya juga perlu disesuaikan.
Cache Poisoning via Unkeyed Inputs terjadi ketika input yang tidak termasuk dalam cache key tetap dapat memengaruhi respons aplikasi. Jika respons tersebut kemudian disimpan oleh cache, pengguna lain berpotensi menerima konten yang telah dimanipulasi.
Risikonya dapat berupa XSS, open redirect, manipulasi konten, hingga denial of service. Oleh karena itu, konfigurasi cache harus dirancang dengan memahami hubungan antara request, cache key, backend, dan respons.
Dengan melakukan audit cache key, membatasi input yang tidak diperlukan, menggunakan validasi yang tepat, serta menonaktifkan caching pada respons sensitif, risiko cache poisoning dapat dikurangi secara signifikan.
Seorang Akademisi, Peneliti dan Praktisi TI, mengajar di beberapa perguruan tinggi, Authorized Training Center dan Lembaga Pengembangan SDM TI. Aktif berbagi di komunitas melalui event webinar & sharing session. aktifitas sehari-hari di isi dengan mengajar, menulis di blog, jurnal, media massa, buku dan juga membuat video tutorial. bidang ilmu yang didalami adalah cybersecurity, system administrator, programming, networking, linux, cloud computing, blockchain, data science, artificial intelligence. visit me at sulkiflysaid.com
