Tingkatkan keamanan dan privasi dengan mengupdate Cache HTTP

Melupakan atau menyalahgunakan header Cache-Control dapat berdampak negatif pada keamanan situs dan privasi pengguna Anda.

Arthur Sonzogni
Arthur Sonzogni

Secara default, resource selalu diizinkan untuk di-cache oleh jenis cache apa pun. Tidak menggunakan atau menyalahgunakan header Cache-Control dapat berdampak negatif pada keamanan situs dan privasi pengguna Anda.

Untuk tanggapan yang dipersonalisasi yang ingin Anda rahasiakan, sebaiknya:

  • Mencegah perantara menyimpan resource ke dalam cache. Tetapkan Cache-Control: private.
  • Tetapkan kunci cache sekunder yang sesuai. Jika respons bervariasi karena cookie—yang dapat terjadi saat cookie menyimpan kredensial—tetapkan Vary: Cookie.

Baca terus untuk mempelajari alasan pentingnya hal ini dan menemukan:

  1. Masalah keamanan dan privasi yang mungkin tidak Anda ketahui
  2. Berbagai jenis cache HTTP dan kesalahpahaman umum
  3. Tindakan yang disarankan untuk situs bernilai tinggi

Resource yang bocor dari kerentanan Spectre

Kerentanan Spectre memungkinkan halaman membaca memori proses OS. Artinya, penyerang dapat mendapatkan akses yang tidak sah ke data lintas origin. Akibatnya, browser web modern telah membatasi penggunaan beberapa fiturnya—seperti SharedArrayBuffer atau timer resolusi tinggi—untuk halaman dengan isolasi lintas-asal.

Browser web modern menerapkan Kebijakan Penyemat Lintas Asal (COEP). Hal ini memastikan resource lintas origin adalah:

  • Resource publik, yang diminta tanpa cookie
  • Resource yang secara eksplisit diizinkan untuk dibagikan lintas-asal, melalui CORS atau header CORP

Penyiapan COEP tidak mencegah penyerang mengeksploitasi Spectre. Namun, hal ini memastikan resource lintas-asal tidak berharga bagi penyerang (saat dimuat oleh browser sebagai resource publik) atau diizinkan untuk dibagikan kepada penyerang (saat dibagikan dengan CORP: cross-origin).

Bagaimana pengaruh caching HTTP terhadap Spectre?

Jika header Cache-Control tidak ditetapkan dengan benar, penyerang dapat menjalankan serangan. Contoh:

  1. Resource dengan kredensial di-cache.
  2. Penyerang memuat halaman yang diisolasi lintas origin.
  3. Penyerang meminta resource lagi.
  4. COEP:credentialless ditetapkan oleh browser, sehingga resource diambil tanpa cookie. Namun, cache dapat menampilkan respons kredensial.
  5. Penyerang kemudian dapat membaca resource yang dipersonalisasi menggunakan serangan Spectre.

Meskipun cache HTTP browser web tidak mengizinkan jenis serangan ini terjadi dalam praktiknya, cache tambahan ada di luar kontrol langsung browser. Hal ini dapat menyebabkan serangan ini berhasil.

Kesalahpahaman umum tentang cache HTTP

1. Resource hanya di-cache oleh browser

Sering kali ada beberapa lapisan cache. Beberapa cache dikhususkan untuk satu pengguna, beberapa untuk beberapa pengguna. Beberapa dikontrol oleh server, beberapa oleh pengguna, dan beberapa oleh perantara.

  • Cache browser. Cache ini dimiliki dan didedikasikan untuk satu pengguna, yang diterapkan di browser web mereka. Cache meningkatkan performa dengan menghindari pengambilan respons yang sama beberapa kali.
  • Proxy lokal. Aplikasi ini mungkin telah diinstal oleh pengguna, tetapi juga dapat dikelola oleh perantara: perusahaan, organisasi, atau penyedia internet mereka. Proxy lokal sering kali meng-cache satu respons untuk beberapa pengguna, yang merupakan cache "publik". Proxy lokal memiliki beberapa peran.
  • Cache server asal / CDN. Hal ini dikontrol oleh server. Tujuan cache server Origin adalah mengurangi beban pada server origin dengan meng-cache respons yang sama untuk beberapa pengguna. Sasaran CDN serupa, tetapi tersebar di seluruh dunia dan ditetapkan ke kumpulan pengguna terdekat untuk mengurangi latensi.
Sering kali ada beberapa lapisan cache antara browser dan server.
Mungkin ada berbagai lapisan cache antara browser dan server. Misalnya, Anda mungkin menemukan cache server, diikuti dengan CDN dan cache browser. Mungkin juga ada penyiapan proxy lokal antara CDN dan cache browser.

2. SSL mencegah perantara menyimpan resource HTTPS ke dalam cache

Banyak pengguna secara rutin menggunakan proxy yang dikonfigurasi secara lokal, baik untuk tujuan akses (seperti berbagi koneksi berbayar), pemeriksaan virus, maupun untuk tujuan pencegahan kebocoran data (DLP). Cache perantara melakukan intersepsi TLS.

Cache perantara sering kali diinstal di workstation karyawan perusahaan. Browser web dikonfigurasi untuk memercayai sertifikat proxy lokal.

Pada akhirnya, beberapa resource HTTPS dapat di-cache oleh proxy lokal ini.

Cara kerja cache HTTP

  • Resource secara implisit diizinkan untuk di-cache secara default.
  • Kunci cache utama terdiri dari URL dan metode. (URL, metode)
  • Kunci cache sekunder adalah header yang disertakan dalam header Vary. Vary: Cookie menunjukkan bahwa respons bergantung pada Cookie.
  • Header Cache-Control memberikan kontrol yang lebih terperinci.

Developer situs bernilai tinggi, yang mencakup situs dengan traffic tinggi dan situs yang berinteraksi dengan informasi identitas pribadi, harus segera bertindak untuk meningkatkan keamanan.

Risiko terbesar terjadi saat akses ke resource bervariasi bergantung pada cookie. Cache perantara dapat menampilkan respons yang diminta dengan cookie untuk permintaan yang tidak diminta jika tidak ada tindakan pencegahan yang dilakukan.

Sebaiknya Anda melakukan salah satu langkah berikut:

  • Mencegah perantara menyimpan resource ke dalam cache. Tetapkan Cache-Control: private.
  • Tetapkan kunci cache sekunder yang sesuai. Jika respons bervariasi karena cookie—yang dapat terjadi saat cookie menyimpan kredensial—tetapkan Vary: Cookie.

Secara khusus, ubah perilaku default: selalu tentukan Cache-Control atau Vary.

Pertimbangan tambahan

Ada jenis serangan lain yang serupa menggunakan cache HTTP, tetapi serangan tersebut bergantung pada mekanisme yang berbeda dari isolasi lintas-asal. Misalnya, Jake Archibald menjelaskan beberapa serangan dalam Cara memenangkan CORS.

Serangan ini dimitigasi oleh beberapa browser web yang memisahkan cache HTTP-nya bergantung pada apakah respons resource diminta dengan kredensial atau tidak. Mulai tahun 2022, Firefox membagi cache, sedangkan Chrome dan Safari tidak. Chrome mungkin memisahkan cache pada masa mendatang. Perhatikan bahwa serangan ini berbeda dan komplementer dengan memisahkannya menurut origin level teratas.

Meskipun masalah ini dapat dimitigasi untuk browser web, masalah tersebut akan tetap ada di cache proxy lokal. Oleh karena itu, sebaiknya Anda tetap mengikuti rekomendasi di atas.

Foto header oleh Ben Pattinson di Unsplash.