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, sumber daya 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.

Untuk respons yang dipersonalisasi yang ingin dirahasiakan, sebaiknya:

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

Baca terus untuk mempelajari mengapa hal ini penting dan temukan:

  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

Kebocoran resource dari kerentanan Spectre

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

Browser web modern menerapkan Cross-Origin Embedder Policy (COEP). Cara ini memastikan resource lintas origin memiliki:

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

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

Bagaimana penyimpanan HTTP ke cache terhadap Spectre?

Jika header Cache-Control tidak disetel dengan benar, penyerang dapat melakukan serangan. Contoh:

  1. Resource berkredensial di-cache.
  2. Penyerang memuat halaman yang diisolasi lintas origin.
  3. Penyerang meminta kembali resource.
  4. COEP:credentialless ditetapkan oleh browser, sehingga resource diambil tanpa cookie. Namun, cache dapat menampilkan respons berkredensial.
  5. Kemudian, penyerang 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 inilah yang menyebabkan keberhasilan serangan ini.

Kesalahpahaman umum tentang cache HTTP

1. Resource hanya di-cache oleh browser

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

  • Cache browser. Cache ini dimiliki oleh dan didedikasikan untuk satu pengguna, yang diimplementasikan di browser web mereka. Keduanya meningkatkan performa dengan menghindari pengambilan respons yang sama beberapa kali.
  • Proxy lokal. Link ini mungkin telah diinstal oleh pengguna, tetapi juga dapat dikelola oleh perantara: perusahaan, organisasi, atau penyedia internet. Proxy lokal sering meng-cache respons tunggal untuk beberapa pengguna, yang merupakan cache "publik". {i>Proxy<i} lokal memiliki beberapa peran.
  • Cache server asal / CDN. Ini dikontrol oleh server. Tujuan cache server Asal adalah untuk mengurangi beban pada server asal dengan meng-cache respons yang sama untuk beberapa pengguna. Tujuan 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 oleh CDN dan cache browser. Mungkin juga ada penyiapan proxy lokal antara CDN dan cache browser.

2. SSL mencegah perantara meng-cache sumber daya HTTPS

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

Cache perantara sering 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 respons bergantung pada Cookie.
  • Header Cache-Control memberikan kontrol yang lebih mendetail.

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

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

Sebaiknya lakukan salah satu langkah berikut:

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

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

Pertimbangan lainnya

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

Serangan ini dimitigasi oleh beberapa browser web yang membagi cache HTTP-nya bergantung pada apakah respons resource diminta dengan kredensial atau tidak. Mulai tahun 2022, Firefox tidak membagi cache, sedangkan Chrome dan Safari tidak. Chrome dapat membagi cache di masa mendatang. Perlu diperhatikan bahwa serangan ini berbeda dan saling melengkapi dengan membaginya per origin tingkat atas.

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

Foto header oleh Ben Pattinson di Unsplash.