Alat pembangun · SHA kalkulator cincang
Integriti Subsumber: Cara Pelayar Menggunakan SHA-384 untuk Menyemak Skrip
· Latar belakang
sha-256 asas64 pelayar-apis keselamatan
Atribut integriti membolehkan pelayar menolak skrip CDN yang baitnya telah berubah. Siaran ini menerangkan format atribut, mengapa SHA-384 dalam base64 ialah pilihan biasa dan perkara yang tidak boleh dilindungi oleh SRI.
CDN yang boleh memberi perkhidmatan kepada apa sahaja — risiko rantaian bekalan SRI direka untuk
Teg skrip pada halaman web boleh membawa atribut integriti: `<script src="https://cdn.example.com/lib.js" integrity="sha384-..."></script>`. Nilai integriti ialah ringkasan kriptografi bait skrip. Apabila pelayar memuat turun skrip, ia mengira ringkasan bait yang diterima dan membandingkan dengan atribut integriti. Jika ia sepadan, skrip dimuatkan. Jika ia tidak sepadan, pelayar enggan memuatkannya dan melaporkan kegagalan dalam konsol. Ini melindungi daripada kod CDN yang dikompromi, atau terhadap penyerang rangkaian yang memintas dan mengubah respons.
Integriti Subsumber (SRI) ialah spesifikasi W3C yang digunakan pada skrip dan helaian gaya. Ia adalah satu-satunya jaminan kriptografi yang boleh dibuat oleh pelayar tentang kandungan sumber silang asal: bait mesti sepadan dengan ringkasan, atau sumber itu ditolak. Ini tidak membuktikan siapa yang mencipta sumber, cuma ia tidak berubah sejak ringkasan dikira. Untuk sumber yang disampaikan melalui HTTPS daripada CDN yang bereputasi, ringkasan menyediakan perlindungan terhadap CDN dikompromi atau menyajikan kandungan cache yang lapuk kepada anda secara khusus.
Atribut integriti — awalan algoritma, sempang, intisari base64 dan sokongan untuk berbilang cincang
Atribut integriti mempunyai format khusus: nama algoritma, sempang, digest dalam base64. Contoh: `integrity="sha384-JZDdQnrrAMe+sxxpn47in+PwhkxrCrt4SNvt+xWqV3zPJUkeFF0Qq/wNtuvNqPP5"`. Nama algoritma boleh SHA-256, SHA-384 atau SHA-512. Base64 ialah pengekodan, bukan perenambelasan; ini adalah pilihan yang disengajakan oleh spesifikasi SRI. Base64 lebih padat daripada hex (kira-kira 33% lebih pendek untuk ringkasan yang sama), yang penting apabila membenamkan dalam atribut HTML. Tanda sempang memisahkan nama algoritma daripada digest. Nilai integriti berbilang boleh disenaraikan, dipisahkan dengan ruang: jika mana-mana satu daripadanya sepadan, sumber itu diterima.
kenapa SHA-384? SRI spesifikasi membolehkan SHA-256, SHA-384 dan SHA-512. SHA-384 menjadi lalai komuniti kerana ia menawarkan saiz/security imbangan. SHA-256 adalah lebih kecil (32 bytes, 44 aksara dalam base64) tetapi SHA-384 adalah lebih luas (48 bytes, 64 aksara dalam base64) dan tidak meningkatkan saiz atribut secara bermakna berbanding dengan SHA-256. SHA-512 tersedia tetapi jarang digunakan kerana cernaannya yang lebih besar nampaknya tidak diperlukan untuk kes penggunaan ini. Pilihan daripada SHA-384 adalah sejarah dan pragmatik, bukan mencerminkan sifat keselamatan yang unggul (ketiga-tiganya adalah kuat dari segi kriptografi untuk tujuan ini).
SHA-384 ditawarkan dan menghasilkan bahan asas64 yang diperlukan; keutamaan komuniti tidak disimpulkan daripada alat tersebut
Pengekodan Base64 dalam SRI ialah base64 standard, bukan base64url. Standard base64 menggunakan + dan / aksara, yang sah dalam atribut HTML tanpa pengekodan peratus, walaupun ia mempunyai makna istimewa dalam URL dan data borang. Format SRI direka untuk atribut HTML, bukan URL, jadi base64 standard adalah sesuai. Jika anda membina nilai integriti dengan tangan, anda mengira digest SHA-384 (jujukan bait), kemudian mengekodkan bait tersebut sebagai base64 standard, kemudian tambahkan `sha384-` dan tampal ke dalam atribut integriti.
Pelayar melakukan langkah yang sama secara terbalik: ekstrak base64 daripada atribut integriti, nyahkod kepada bait untuk memulihkan ringkasan, mengira SHA-384 bait skrip yang dimuat turun dan membandingkan dua nilai ringkasan. Mereka mesti sepadan dengan tepat; perbezaan bit tunggal dalam penghadaman menyebabkan penolakan. Tiada padanan kabur atau kredit separa: integriti adalah binari.
Tingkah laku SRI silang asal memerlukan dokumentasi pelayar di luar kalkulator cincang ini
SRI memerlukan CORS pada respons silang asal. Jika anda memuatkan skrip daripada asal yang berbeza, pelayan mesti bertindak balas dengan `Access-Control-Allow-Origin: *` atau pengepala asal tertentu yang termasuk milik anda. Tanpa pengepala CORS, pelayar tidak boleh menyemak SRI, kerana tanpa CORS ia tidak dapat mengesahkan bahawa badan respons sepadan dengan perkara yang ingin dihantar oleh pelayan. Pengepala CORS ialah pernyataan pelayan bahawa respons ini selamat untuk diperiksa; SRI ialah semak anda bahawa bait adalah betul. Bersama-sama, mereka membentuk komitmen rantaian bekalan: pelayan membenarkan anda mengesahkan kandungan, dan anda melakukannya.
Jika skrip silang asal tidak mempunyai pengepala CORS dan mempunyai atribut integriti, pelayar akan memuat turunnya (jika skrip dari asal itu dibenarkan oleh CSP tapak), tetapi ia tidak akan mengesahkan integriti. Skrip akan dimuatkan seolah-olah atribut integriti tiada. Ini bukan kegagalan SRI; ia adalah sempadan keselamatan: anda tidak boleh mengesahkan respons yang anda tidak boleh baca.
Perkara yang berlaku pada ketidakpadanan — pelayar menyekat sumber dan laporan dalam konsol
Apabila pelayar mengesan ketidakpadanan integriti, ia enggan melaksanakan skrip dan log mesej dalam konsol pelayar. Mesej itu biasanya menamakan URL, cincang yang dijangka dan cincang yang dikira. Kegagalan adalah atom: sama ada sumber dimuatkan seperti sedia ada atau ditolak sepenuhnya. Tiada pemuatan separa atau sandaran. Jika tapak web bergantung pada skrip itu dan ia ditolak, tapak tersebut mungkin pecah. Ini disengajakan: menghantar kod yang salah adalah lebih teruk daripada menghantar tanpa kod, dan kegagalan senyap membolehkan serangan berterusan selama-lamanya.
Menguji persediaan SRI adalah mudah: buka konsol pelayar, muatkan halaman dan cari mesej tentang ketidakpadanan integriti. Jika anda melihat ketidakpadanan, bandingkan cincang yang dikira yang ditunjukkan dalam konsol dengan cincang dalam atribut integriti anda. Jika ia tidak sepadan, hitung semula: skrip mungkin telah dikemas kini dan anda memerlukan ringkasan baharu.
Contoh yang berkesan — mengira ringkasan untuk skrip dan memformatkannya menjadi nilai integriti, termasuk langkah base64
Mengira ringkasan SRI secara manual sahaja memerlukan bait skrip dan alat cincang. Muat turun skrip, tampalkannya ke dalam kalkulator cincang ToolAcre SHA, pilih SHA-384, salin output base64 (bukan hex), tambahkan `sha384-` dan tampal pada atribut integriti. Jika skripnya besar, gunakan curl atau wget untuk menyimpannya ke fail dan kemudian membaca fail itu lebih cepat daripada menampal. Untuk skrip sebaris (dalam teg `<script>` dalam HTML dan bukannya daripada URL), SRI tidak berkenaan; skrip sebaris sentiasa dipercayai mengikut definisi. SRI adalah untuk sumber luaran.
Contoh yang berjaya: katakan anda ingin memuatkan jQuery daripada CDN dengan SRI. Cari skrip URL, muat turunnya (atau gunakan curl untuk mengambilnya), tampal bait ke dalam kalkulator atau gunakan `sha384sum` pada baris arahan, dapatkan ringkasan SHA-384 sebagai base64 dan format sebagai `sha384-[base64-digest]`. Tampalkan ke dalam atribut integriti teg skrip. Muatkan halaman dan sahkan tiada ralat konsol muncul.
Perkara ini tidak meliputi — skrip yang berubah dengan sengaja dan tapak seperti ToolAcre yang tidak memuatkan skrip luaran sama sekali dan tidak mempunyai apa-apa untuk disematkan
SRI tidak melindungi daripada semua serangan rantaian bekalan. Ia melindungi daripada bait yang berubah selepas ringkasan dikira, tetapi tidak terhadap ringkasan yang dikira daripada kod terjejas untuk bermula. Jika CDN dikompromi sebelum anda mengira ringkasan, SRI tidak dapat membantu. Intisari sahaja boleh dipercayai seperti sumber dari mana anda mengiranya. Untuk jaminan maksimum, hitung ringkasan daripada sumber asal (contohnya, keluaran GitHub perpustakaan) dan gunakan ringkasan tersebut apabila memuatkan daripada CDN. Digest menjadi komitmen daripada penyelenggara melalui proses pelepasan.
SRI juga tidak melindungi daripada rangkaian terjejas pada masa anda mengira ringkasan, atau terhadap mesin pembangunan terjejas. Ia sahaja melindungi daripada perubahan pada skrip antara masa ringkasan dibuat dan masa pelayar memuatkan skrip. Untuk jaminan berterusan, sesetengah penempatan menggunakan tandatangan keluaran sebagai tambahan kepada SRI: keluaran ditandatangani oleh kunci penyelenggara, anda mengesahkan tandatangan, mengira ringkasan daripada bait yang disahkan dan menggunakannya dalam SRI.
Artikel ini tidak menegaskan inventori skrip luaran seluruh tapak ToolAcre daripada sumber cincang
Kalkulator cincang ToolAcre SHA mengeluarkan ringkasan dalam base64 standard secara langsung (sebagai `base64` output daripada fungsi `toBase64()`). Untuk menukar kepada format SRI, tambahkan nama algoritma dan tanda sempang: `sha256-`, `sha384-` atau `sha512-`. Kalkulator tidak menggunakan awalan itu secara automatik kerana cincang muncul dalam banyak konteks (git, Docker, npm, URL) di mana nama algoritma diasingkan atau dikodkan secara berbeza. Sempadannya jelas: kalkulator mencincang UTF-8 teks yang anda tampal, bukan fail atau kekunci binari. Ia mengeluarkan kedua-dua hex dan base64. Anda memilih mana yang hendak digunakan berdasarkan konteks anda. Untuk SRI, base64 diperlukan oleh spesifikasi. Untuk git dan alat lain, hex adalah konvensional. Untuk npm dan Go, base64 digunakan. Pilihan pengekodan adalah milik anda; bait digest adalah sama.
SRI kekal sebagai salah satu daripada beberapa semakan kriptografi yang boleh dilakukan oleh pelayar tanpa kuasa berpusat. Pengkomputeran mencerna diri anda dengan alat yang dipercayai seperti kalkulator ToolAcre SHA dan mengesahkannya terhadap sumber yang dimuatkan ialah cara yang boleh diakses untuk mengeraskan tapak web daripada serangan rantaian bekalan tertentu. Perlindungan sahaja sebaik penghadaman; hitung semula selepas setiap kemas kini kepada sumber luaran dan uji bahawa pelayar memuatkan skrip tanpa menolaknya.