Subresource Integrity Mengikat Aset Eksternal ke Konten yang Diharapkan
Halaman yang memuat JavaScript atau CSS dari host lain memberi host tersebut jalur langsung ke konteks eksekusi atau presentasi halaman. HTTPS melindungi transfer dari manipulasi jaringan, tetapi tidak memberi tahu browser apakah server mengirim aset persis seperti yang dimaksud aplikasi.
Subresource Integrity (SRI) menambahkan pemeriksaan konten. Dokumen membawa metadata kriptografis untuk sebuah resource. Setelah mengambil byte, browser menghitung digest yang relevan dan membandingkannya dengan metadata sebelum menerima resource tersebut.
<script
src="https://cdn.example.net/app.min.js"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"></script>Digest terikat pada byte resource, bukan sekadar URL-nya. Response dengan byte berbeda gagal melewati pemeriksaan integrity meski datang dari hostname yang benar melalui koneksi TLS yang valid.
Metadata integrity menjadi komitmen atas konten
Nilai integrity memuat satu atau beberapa ekspresi hash. Setiap ekspresi menyebut algoritma hash yang didukung dan membawa digest yang dikodekan dengan base64.
sha384-BASE64_DIGESTUntuk metadata SRI saat ini, prefix algoritma yang ditetapkan mencakup sha256, sha384, dan sha512. Ketika metadata memuat hash yang dikenali dari algoritma dengan kekuatan berbeda, pemrosesan browser memilih kumpulan algoritma terkuat yang berlaku lalu membandingkan resource yang diambil dengan hash dalam kumpulan tersebut.
Beberapa hash dengan algoritma terpilih dapat mendukung transisi yang disengaja di antara versi aset yang telah ditetapkan. Kecocokan dengan digest yang memenuhi syarat membuat pemeriksaan integrity berhasil; perbedaan membuat pemuatan resource gagal.
Perilaku ini menjadikan dokumen HTML sebagai deklarasi konten yang dapat diterima, bukan deklarasi bahwa byte apa pun pada URL tertentu dapat diterima.
SRI lintas origin juga bergantung pada CORS
Pemeriksaan integrity tidak melewati aturan fetch lintas origin. Untuk resource yang diambil dari origin lain, SRI mengharuskan response memenuhi CORS. Bentuk script yang umum karena itu menggabungkan integrity dengan crossorigin="anonymous".
<script
src="https://static.example.net/runtime.js"
integrity="sha384-BASE64_DIGEST"
crossorigin="anonymous"></script>Server resource harus mengirim header response Access-Control-Allow-Origin yang sesuai. Jika response lintas origin tidak memenuhi pemrosesan CORS yang diperlukan, browser tidak dapat memperlakukan hash integrity sebagai izin untuk memakai resource tersebut.
Ada dua pemeriksaan terpisah: CORS mengatur apakah response lintas origin dapat digunakan untuk pemuatan, sedangkan SRI memeriksa apakah kontennya cocok dengan metadata yang disetujui.
Pembaruan aset memerlukan pembaruan metadata
Hash konten berubah ketika byte yang dilindungi berubah. Sifat ini merupakan inti SRI, sekaligus menciptakan ketergantungan operasional antara publikasi aset dan deployment HTML.
Jika CDN mengganti runtime.js dengan build baru sementara dokumen masih membawa digest lama, browser menolak byte baru. Jika dokumen diperbarui dengan digest baru sebelum aset baru tersedia secara konsisten, client dapat mengalami ketidakcocokan sebaliknya.
URL aset berversi mengurangi masalah koordinasi ini:
/assets/runtime.4f29c1.js
/assets/runtime.91a720.jsDeployment dapat menerbitkan aset immutable baru lebih dulu, lalu menerbitkan markup yang merujuk URL dan digest-nya. Menjaga aset versi lama tetap tersedia selama peralihan cache juga menghindari pemaksaan satu URL untuk mewakili beberapa urutan byte.
Karena itu, SRI paling rapi dipakai bersama aset statis yang immutable atau memiliki versi eksplisit.
Hash yang valid tidak membuat kode menjadi aman
SRI memverifikasi kesamaan byte terhadap metadata yang diberikan dokumen. SRI tidak memeriksa JavaScript untuk mencari perilaku berbahaya, tidak membuktikan dependency bebas cacat, dan tidak menetapkan bahwa pihak yang menghasilkan digest yang diharapkan dapat dipercaya.
Jika penyerang dapat mengubah resource sekaligus halaman yang memuat metadata integrity, penyerang dapat mengganti keduanya. SRI paling berguna ketika dokumen yang dilindungi dan aset eksternal tidak berada dalam batas kompromi yang sama.
Kontrol ini juga berbeda dari Content Security Policy. CSP dapat membatasi sumber script dan pola eksekusi yang diizinkan. SRI dapat mengikat resource eksternal tertentu ke byte yang diharapkan. Deployment dapat memakai keduanya karena kondisi yang ditegakkan berbeda.
Pipeline build sebaiknya menghasilkan hash dari artifact rilis
String integrity yang dipelihara secara manual mudah tidak sinkron dengan file yang dilindunginya. Pipeline rilis dapat menghitung metadata dari artifact persis yang akan diterbitkan, lalu menempatkan nilai tersebut ke markup hasil generate atau manifest yang dipakai build situs.
Alur digest secara umum berbentuk:
artifact rilis
|
+--> terbitkan byte immutable
|
+--> hitung digest
|
v
metadata integrity
|
v
markup hasil generateProperti pentingnya adalah provenance: digest harus sesuai dengan byte yang sama yang sampai ke host aset. Membangun ulang package yang secara nominal identik pada langkah terpisah dapat menghasilkan byte berbeda ketika build tidak reproducible.
Validasi dapat mengambil aset yang telah di-deploy, menghitung digest-nya, lalu membandingkannya dengan markup sebelum rilis dipromosikan. Langkah ini menangkap kesalahan publikasi tanpa mengubah peran enforcement browser.
Cakupan lebih penting daripada penerapan yang terisolasi
Menambahkan SRI ke satu script membuat aset eksternal lain yang memenuhi syarat tetap berada di luar pemeriksaan konten tersebut. Inventaris aset dapat mengidentifikasi script dan resource tertaut yang melintasi batas trust, lalu mencatat mana yang membawa metadata integrity dan mana yang sengaja dikecualikan.
SRI berlaku pada elemen script serta relasi link yang didukung seperti stylesheet, preload, dan module preload. Dukungan browser dan mode fetch yang tepat tetap perlu diperhatikan untuk setiap jenis resource.
Tinjauan praktis juga perlu mencakup aset yang diinjeksi saat runtime. Pemeriksaan HTML statis saja dapat melewatkan resource yang dirakit oleh kode aplikasi atau loader pihak ketiga.
SRI mempersempit trust pada host eksternal
Tanpa SRI, halaman yang memuat aset eksternal yang memenuhi syarat pada umumnya menerima byte yang dikembalikan untuk request tersebut, dengan tetap tunduk pada kontrol keamanan browser lainnya. Dengan metadata integrity yang valid, halaman dapat mewajibkan byte tersebut cocok dengan digest kriptografis yang dideklarasikan.
Batas ini sengaja sempit. SRI tidak mengamankan lifecycle dependency dan tidak menggantikan source review, CSP, CORS, TLS, artifact signing, atau kontrol deployment. SRI memberi browser satu kondisi presisi saat pemuatan: resource yang diambil harus menjadi salah satu urutan byte yang secara eksplisit diterima dokumen.
Referensi
- MDN, Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
- W3C, Subresource Integrity: https://www.w3.org/TR/SRI/