Alat pengembang · SHA kalkulator hash
Integritas Subsumber Daya: Bagaimana Browser Menggunakan SHA-384 untuk Memeriksa Skrip
· Latar belakang
sha-256 base64 browser-apis keamanan
Atribut integritas memungkinkan browser menolak skrip CDN yang byte-nya telah diubah. Posting ini menjelaskan format atribut, mengapa SHA-384 di base64 adalah pilihan umum, dan apa yang SRI tidak dapat lindungi.
CDN yang dapat melayani apa saja — risiko rantai pasokan SRI dirancang untuk
Tag skrip pada halaman web dapat membawa atribut integritas: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. Nilai integritas adalah intisari kriptografi dari byte skrip. Saat browser mengunduh skrip, browser menghitung intisari byte yang diterima dan membandingkannya dengan atribut integritas. Jika cocok, skrip dimuat. Jika tidak cocok, browser menolak memuatnya dan melaporkan kegagalan di konsol. Hal ini melindungi terhadap CDN yang disusupi yang menyajikan kode yang dimodifikasi, atau terhadap penyerang jaringan yang mencegat dan mengubah respons.
Integritas Subsumber Daya (SRI) adalah spesifikasi W3C yang berlaku untuk skrip dan stylesheet. Ini adalah satu-satunya jaminan kriptografi yang dapat dibuat oleh browser mengenai konten sumber daya lintas asal: byte harus cocok dengan intisari, atau sumber daya ditolak. Hal ini tidak membuktikan siapa yang menciptakan sumber daya, hanya saja sumber daya tersebut tidak berubah sejak intisari dihitung. Untuk sumber daya yang disajikan selama HTTPS dari CDN yang memiliki reputasi baik, intisari memberikan perlindungan terhadap CDN yang disusupi atau menyajikan konten cache basi kepada Anda secara khusus.
Atribut integritas — awalan algoritme, tanda hubung, intisari base64, dan dukungan untuk banyak hash
Atribut integritas memiliki format tertentu: nama algoritma, tanda hubung, intisari di base64. Contoh: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. Nama algoritme dapat berupa SHA-256, SHA-384, atau SHA-512. Base64 adalah pengkodean, bukan heksadesimal; ini adalah pilihan yang disengaja berdasarkan spesifikasi SRI. Base64 lebih ringkas daripada hex (sekitar 33% lebih pendek untuk intisari yang sama), yang penting saat menyematkan atribut HTML. Tanda hubung memisahkan nama algoritma dari intisari. Beberapa nilai integritas dapat dicantumkan, dipisahkan spasi: jika salah satu dari nilai tersebut cocok, sumber daya diterima.
Mengapa SHA-384? Spesifikasi SRI memungkinkan SHA-256, SHA-384 dan SHA-512. SHA-384 menjadi default komunitas karena menawarkan saldo size/security. SHA-256 lebih kecil (32 bytes, 44 karakter di base64) tetapi SHA-384 lebih lebar (48 bytes, 64 karakter di base64) dan tidak meningkatkan ukuran atribut secara signifikan dibandingkan dengan SHA-256. SHA-512 tersedia tetapi jarang digunakan karena intisarinya yang lebih besar tampaknya tidak diperlukan untuk kasus penggunaan ini. Pilihan SHA-384 bersifat historis dan pragmatis, bukan mencerminkan sifat keamanan yang unggul (ketiganya kuat secara kriptografis untuk tujuan ini).
SHA-384 ditawarkan dan menghasilkan material base64 yang dibutuhkan; preferensi komunitas tidak disimpulkan dari alat ini
Pengkodean Base64 di SRI adalah base64 standar, bukan base64url. Base64 standar menggunakan karakter + dan /, yang valid dalam atribut HTML tanpa pengkodean persen, meskipun karakter tersebut memiliki arti khusus dalam URL dan data formulir. Format SRI dirancang untuk atribut HTML, bukan URL, sehingga standar base64 sesuai. Jika Anda membangun nilai integritas dengan tangan, Anda menghitung intisari SHA-384 (urutan byte), lalu mengkodekan byte tersebut sebagai base64 standar, lalu menambahkan `sha384-` dan menempelkannya ke atribut integritas.
Browser melakukan langkah yang sama secara terbalik: mengekstrak base64 dari atribut integritas, mendekode ke byte untuk memulihkan intisari, menghitung SHA-384 dari byte skrip yang diunduh dan membandingkan dua nilai intisari. Mereka harus sama persis; perbedaan satu bit dalam intisari menyebabkan penolakan. Tidak ada pencocokan fuzzy atau kredit parsial: integritas bersifat biner.
Perilaku SRI lintas asal memerlukan dokumentasi browser selain kalkulator hash ini
SRI memerlukan CORS pada respons lintas asal. Jika Anda memuat skrip dari asal yang berbeda, server harus merespons dengan `Access-Control-Allow-Origin: *` atau header asal tertentu yang mencakup milik Anda. Tanpa header CORS, browser tidak dapat memeriksa SRI, karena tanpa CORS browser tidak dapat memastikan bahwa isi respons cocok dengan apa yang ingin dikirim oleh server. CORS header adalah pernyataan server bahwa respons ini aman untuk diperiksa; SRI adalah pemeriksaan Anda apakah byte sudah benar. Bersama-sama, mereka membentuk komitmen rantai pasokan: server memungkinkan Anda memverifikasi konten, dan Anda melakukannya.
Jika skrip lintas asal tidak memiliki header CORS dan memiliki atribut integritas, browser akan mengunduhnya (jika skrip dari asal tersebut diizinkan oleh CSP situs), namun skrip tersebut tidak akan memverifikasi integritasnya. Skrip akan dimuat seolah-olah atribut integritas tidak ada. Ini bukan kegagalan SRI; ini adalah batas keamanan: Anda tidak dapat memverifikasi respons yang tidak dapat Anda baca.
Apa yang terjadi jika ketidakcocokan — browser memblokir sumber daya dan laporan di konsol
Saat browser mendeteksi ketidakcocokan integritas, browser menolak menjalankan skrip dan mencatat pesan di konsol browser. Pesan tersebut biasanya menyebutkan URL, hash yang diharapkan, dan hash yang dihitung. Kegagalannya bersifat atomik: sumber daya dimuat apa adanya atau ditolak seluruhnya. Tidak ada pemuatan sebagian atau fallback. Jika situs web mengandalkan skrip tersebut dan ditolak, situs tersebut mungkin rusak. Hal ini disengaja: mengirimkan kode yang salah lebih buruk daripada tidak mengirimkan kode apa pun, dan kegagalan diam-diam memungkinkan serangan terus berlanjut tanpa batas waktu.
Menguji penyiapan SRI sangatlah mudah: buka konsol browser, muat laman, dan cari pesan tentang ketidakcocokan integritas. Jika Anda melihat ketidakcocokan, bandingkan hash terhitung yang ditampilkan di konsol dengan yang ada di atribut integritas Anda. Jika tidak cocok, hitung ulang: skrip mungkin telah diperbarui dan Anda memerlukan intisari baru.
Contoh praktis - menghitung intisari skrip dan memformatnya menjadi nilai integritas, termasuk langkah base64
Menghitung intisari SRI secara manual hanya memerlukan byte skrip dan alat hash. Unduh skrip, tempelkan ke kalkulator hash ToolAcre SHA, pilih SHA-384, salin keluaran base64 (bukan hex), tambahkan `sha384-` dan tempel ke atribut integritas. Jika skrip berukuran besar, gunakan curl atau wget untuk menyimpannya ke file dan kemudian membaca file lebih cepat daripada menempelkannya. Untuk skrip sebaris (dalam tag `<script>` di HTML dan bukan dari URL), SRI tidak berlaku; skrip inline selalu dipercaya menurut definisinya. SRI ditujukan untuk sumber daya eksternal.
Contoh praktis: misalkan Anda ingin memuat jQuery dari CDN dengan SRI. Temukan skrip URL, unduh (atau gunakan curl untuk mengambilnya), tempelkan byte ke dalam kalkulator atau gunakan `sha384sum` pada baris perintah, dapatkan intisari SHA-384 sebagai base64, dan format sebagai `sha384-[base64-digest]`. Tempelkan ke dalam atribut integritas tag skrip. Muat halaman dan pastikan tidak ada kesalahan konsol yang muncul.
Yang tidak tercakup dalam hal ini — skrip yang diubah dengan sengaja, dan situs seperti ToolAcre yang tidak memuat skrip eksternal sama sekali sehingga tidak ada yang perlu dipasangi pin
SRI tidak melindungi dari semua serangan rantai pasokan. Ini melindungi terhadap perubahan byte setelah intisari dihitung, tetapi tidak terhadap intisari yang dihitung dari kode yang dikompromikan untuk memulai. Jika CDN disusupi sebelum Anda menghitung intisarinya, SRI tidak dapat membantu. Intisarinya hanya dapat dipercaya jika sumbernya Anda menghitungnya. Untuk jaminan maksimum, hitung intisari dari sumber asli (rilis GitHub perpustakaan, misalnya) dan gunakan intisari tersebut saat memuat dari CDN. Intisarinya menjadi komitmen pengelola melalui proses pelepasan.
SRI juga tidak melindungi terhadap jaringan yang disusupi pada saat Anda menghitung intisari, atau terhadap mesin pengembangan yang disusupi. Ini hanya melindungi terhadap perubahan skrip antara waktu intisari dibuat dan waktu browser memuat skrip. Untuk jaminan berkelanjutan, beberapa penerapan menggunakan penandatanganan rilis selain SRI: rilis ditandatangani oleh kunci pengelola, Anda memverifikasi tanda tangan, menghitung intisari dari byte terverifikasi dan menggunakannya di SRI.
Artikel ini tidak menegaskan inventaris skrip eksternal seluruh situs ToolAcre dari sumber hash
Kalkulator hash ToolAcre SHA memancarkan intisari dalam base64 standar secara langsung (sebagai keluaran `base64` dari fungsi `toBase64()`). Untuk mengonversi ke format SRI, tambahkan nama algoritma dan tanda hubung: `sha256-`, `sha384-` atau `sha512-`. Kalkulator tidak menerapkan awalan tersebut secara otomatis karena hash muncul dalam banyak konteks (git, Docker, npm, URL) dengan nama algoritme terpisah atau dikodekan secara berbeda. Batasannya jelas: kalkulator meng-hash UTF-8 teks yang Anda tempel, bukan file atau kunci biner. Ini menghasilkan hex dan base64. Anda memilih mana yang akan digunakan berdasarkan konteks Anda. Untuk SRI, base64 diperlukan oleh spesifikasi. Untuk git dan alat lainnya, hex bersifat konvensional. Untuk npm dan Go, base64 digunakan. Pilihan pengkodean ada di tangan Anda; byte intisarinya sama.
SRI tetap menjadi salah satu dari sedikit pemeriksaan kriptografi yang dapat dilakukan browser di sisi klien tanpa otoritas terpusat. Menghitung intisari Anda sendiri dengan alat tepercaya seperti kalkulator SHA milik ToolAcre dan memverifikasinya terhadap sumber daya yang dimuat adalah cara yang dapat diakses untuk memperkuat situs web terhadap serangan rantai pasokan tertentu. Perlindungannya hanya sebaik pencernaannya; menghitung ulang setelah setiap pembaruan pada sumber daya eksternal dan menguji apakah browser memuat skrip tanpa menolaknya.