Memahami Integritas Sub-Sumber Daya
Diterbitkan: 2022-03-10 Jika Anda pernah menggunakan versi library JavaScript yang dihosting CDN, Anda mungkin memperhatikan atribut integrity yang tampak aneh pada tag skrip. Atribut ini berisi sampah alfanumerik yang tampaknya tak ada habisnya yang mungkin tergoda untuk Anda hapus dalam pencarian kode yang lebih bersih.
Semua sampah itu sebenarnya adalah fitur keamanan yang sangat berguna yang disebut Subresource Integrity (SRI) yang dapat membantu mempertahankan situs Anda dari jenis peretasan dan penyusupan tertentu. Dalam artikel ini, kita akan melihat apa itu SRI, bagaimana SRI dapat membantu melindungi Anda, dan bagaimana Anda dapat mulai menggunakannya dalam proyek Anda sendiri, tidak hanya untuk file yang dihosting di CDN.
Sedikit sejarah
Jauh di masa-masa ketika JavaScript adalah sepupu yang lebih buruk dari HTML dan CSS, kami tidak perlu terlalu memikirkan bagaimana skrip kami dapat digunakan sebagai vektor serangan untuk situs web kami. Sebagian besar situs semua dihosting di satu server fisik di suatu tempat di infrastruktur hosting kami sendiri, dan itu adalah server yang kami pikirkan untuk dipertahankan dalam hal praktik terbaik keamanan.
Ketika browser menjadi lebih mampu dan koneksi internet menjadi lebih gemuk, kami mulai menggunakan lebih banyak JavaScript, dan akhirnya, perpustakaan JavaScript yang dapat digunakan kembali mulai bermunculan. Pada hari-hari awal, perpustakaan seperti script.aculo.us, Prototype dan akhirnya jQuery mulai mendapatkan adopsi di antara pengembang yang ingin menambahkan lebih banyak interaktivitas ke halaman mereka.
Dengan perpustakaan tambahan ini dan plugin berikutnya, bobot halaman bertambah, dan tak lama kemudian kami mulai berpikir serius tentang kinerja front-end. Sumber daya seperti Jaringan Pengiriman Konten (CDN) yang sebelumnya menjadi cadangan perusahaan raksasa menjadi biasa untuk membangun situs web cepat orang sehari-hari.
Sepanjang jalan, beberapa percikan terang memperhatikan bahwa semua situs meminta salinan perpustakaan umum mereka sendiri — hal-hal seperti jQuery terbaru — dan jika ada versi CDN umum dari perpustakaan tersebut yang dapat digunakan oleh setiap situs, maka pengguna tidak akan ' Anda tidak perlu terus mengunduh file yang sama. Mereka akan menerima pukulan untuk situs pertama yang menggunakan file tersebut, tetapi kemudian file itu akan tersimpan di cache browser lokal mereka dan unduhan dapat dilewati untuk setiap situs berikutnya. Jenius!
Inilah sebabnya mengapa Anda akan melihat tautan CDN untuk perpustakaan favorit Anda menggunakan URL seperti jsdelivr.com — mereka menggunakan CDN umum untuk meng-host file sehingga penggunanya melihat manfaat kinerja.
Apa yang Bisa Salah?
Ini tetap merupakan cara yang baik dan praktis untuk bekerja, tetapi ini memperkenalkan vektor potensial untuk serangan. Mari kita bayangkan bahwa ini tahun 2012 dan semua orang menggunakan jQuery 1.8 yang baru. Kembali dengan cara tradisional dalam melakukan sesuatu, setiap orang akan memiliki file jQuery 1.8 mereka sendiri yang dihosting sebagai bagian dari situs web mereka sendiri di server mereka sendiri.
Jika Anda adalah semacam aktor jahat — seperti semacam Hamburglar berbasis jQuery — dan telah menemukan cara licik untuk meretas perpustakaan demi keuntungan jahat Anda sendiri, Anda harus menargetkan setiap situs web satu per satu dan mengkompromikan server mereka untuk memilikinya. dampak apapun. Itu banyak usaha.
Tapi bukan itu yang terjadi sekarang, karena semua orang menggunakan jQuery yang dimuat dari CDN umum. Dan ketika saya mengatakan semua orang, maksud saya bukan ratusan halaman web. Maksud saya jutaan halaman web. Tiba-tiba satu file itu menjadi target yang sangat menarik bagi peretas kami. Jika mereka dapat mengkompromikan satu file itu, mereka dapat dengan cepat menjalankan kode di jutaan halaman web di seluruh dunia.
Tidak masalah apa kode itu. Itu bisa berupa lelucon untuk merusak halaman, bisa berupa kode untuk mencuri kata sandi Anda, bisa berupa kode untuk menambang cryptocurrency, atau bisa juga pelacak licik untuk mengikuti Anda di web dan membuat profil pemasaran. Yang penting adalah bahwa file tidak bersalah yang ditambahkan pengembang ke halaman telah diubah dan Anda sekarang memiliki beberapa JavaScript jahat yang berjalan sebagai bagian dari situs Anda. Itu masalah besar.
Masukkan Integritas Subsumberdaya
Daripada memutar kembali waktu dan meninggalkan cara yang berguna untuk menggunakan kode, SRI adalah solusi yang menambahkan tingkat keamanan sederhana di atas. Apa yang dilakukan SRI dan atribut integrity adalah memastikan bahwa file yang Anda tautkan ke halaman tidak pernah berubah. Dan jika itu berubah, maka browser akan menolaknya.
Memeriksa bahwa kode tidak berubah adalah masalah yang sangat lama dalam ilmu komputer dan untungnya ia memiliki beberapa solusi yang sangat mapan. SRI melakukan pekerjaan yang baik dengan mengadopsi hashing file yang paling sederhana.
File hashing adalah proses mengambil file dan menjalankannya melalui algoritma yang mereduksinya menjadi representasi string pendek, yang dikenal sebagai hash atau checksum. Tanpa masuk ke gulma, prosesnya dapat berulang atau reversibel, sedemikian rupa sehingga jika Anda memberi orang lain file bersama dengan hash, mereka dapat menjalankan algoritme yang sama untuk memeriksa apakah keduanya cocok. Jika file berubah atau hash berubah, maka tidak ada lagi kecocokan dan Anda tahu ada yang salah dan harus tidak mempercayai file tersebut.
Saat menggunakan SRI, halaman web Anda menyimpan hash dan server (CDN atau di mana saja) menyimpan file tersebut. Peramban mengunduh file, lalu dengan cepat menghitung untuk memastikan bahwa itu cocok dengan hash dalam atribut integrity . Jika cocok maka file yang digunakan, dan jika tidak maka diblokir.
Mencobanya
Jika saya pergi ke getbootstrap.com hari ini untuk mendapatkan tautan CDN ke versi Bootstrap, saya diberi tag yang terlihat seperti ini:
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script> Anda dapat melihat bahwa atribut src adalah seperti yang biasa kita gunakan, dan atribut integrity memegang apa yang sekarang kita ketahui sebagai hash.
Hash sebenarnya dalam dua bagian. Yang pertama adalah awalan untuk mendeklarasikan algoritma hashing mana yang akan digunakan. Dalam hal ini, itu sha384 . Ini diikuti oleh tanda hubung dan kemudian hash itu sendiri, dikodekan dengan base64 .
Anda mungkin akrab dengan base64 sebagai cara untuk mengkodekan file sebaris seperti gambar ke dalam halaman. Ini bukan proses kriptografi — ini hanya cara cepat dan nyaman untuk mengkodekan data yang berpotensi berantakan dengan cara yang diterjemahkan dengan rapi ke ASCII. Inilah sebabnya mengapa ini banyak digunakan di web.
Saat melihat ini, browser akan mengunduh bootstrap.min.js . Sebelum menjalankannya, base64 akan mendekode hash dan kemudian menggunakan algoritme hashing sha384 untuk mengonfirmasi bahwa hash cocok dengan file yang baru saja diunduh. Jika cocok, file akan dieksekusi.
Saya dapat menguji ini dengan meletakkan tag itu di halaman, dan kemudian membuka tab Jaringan di alat browser saya untuk melihat bahwa file telah dimuat.
Saya dapat melihat bahwa bootstrap.min.js (dan juga file jQuery yang dibutuhkan) telah berhasil dimuat.
Mari kita lihat apa yang akan terjadi jika saya memperbarui hash menjadi sesuatu yang saya tahu salah.
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-SmashingMagazineIsCoolForCats" crossorigin="anonymous"></script> 
Seperti yang Anda lihat, hash yang ditentukan di halaman saya tidak lagi cocok dengan file tersebut, sehingga file tersebut diblokir.
Menggunakan SRI Dalam Proyek Anda Sendiri
Memiliki kemampuan ini untuk perpustakaan pada CDN sangat bagus, dan jika Anda melihat opsi untuk menggunakan file yang disematkan dengan atribut integrity maka Anda pasti harus menyukai opsi itu. Tapi itu tidak terbatas pada proyek besar di CDN, Anda dapat menggunakannya sendiri untuk situs Anda sendiri.
Sama sekali tidak masuk akal untuk membayangkan skenario di mana seorang peretas berhasil mendapatkan akses hanya ke beberapa file di situs Anda. Saya pikir sebagian besar dari kita telah melihat klien, kolega, atau teman yang pada suatu saat memiliki situs WordPress yang dikompromikan dengan banyak sampah jahat yang bahkan tidak mereka sadari ada di sana.
SRI dapat melindungi Anda dari ini juga. Jika Anda membuat hash integritas untuk file Anda sendiri, maka Anda dapat membuat situs Anda menolak perubahan apa pun seperti halnya untuk file yang dihosting dari jarak jauh.
Menghasilkan Hash
Anda dapat, seperti yang Anda harapkan, menjalankan beberapa perintah di terminal komputer Anda untuk menghasilkan hash untuk sebuah file. Contoh cara melakukannya berasal dari halaman Integritas Subsumber Daya MDN:
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A Itu mendapatkan konten FILENAME.js dan meneruskannya sebagai input ke openssl untuk membuat intisari menggunakan sha384 , yang kemudian diteruskan sebagai input ke perintah openssl lain ke base64 menyandikan hasilnya. Tidak hanya rumit dan tidak jelas, tetapi juga bukan hal yang ingin Anda lakukan dengan tangan setiap kali file JavaScript Anda berubah.
Lebih berguna lagi, Anda ingin mengintegrasikan ini entah bagaimana ke dalam proses pembuatan situs Anda, dan seperti yang Anda bayangkan, ada banyak opsi yang sudah jadi di sana. Implementasi yang tepat akan sangat bervariasi berdasarkan proyek Anda, tetapi berikut adalah beberapa blok bangunan.
Jika Anda menggunakan Gulp untuk membangun situs Anda, ada gulp-sri yang akan menampilkan file JSON dengan daftar file Anda dan hashnya. Anda kemudian dapat menggunakan ini di situs Anda. Misalnya, untuk situs yang dirender secara dinamis, Anda dapat membuat plugin template untuk membaca file tersebut dan menambahkan hash ke template jika diperlukan.
Jika Anda masih menggunakan Gulp tetapi memiliki situs statis (atau situs yang dibuat secara statis), Anda dapat menggunakan gulp-sri-hash yang akan benar-benar berjalan melalui halaman HTML Anda dan memodifikasi halaman untuk menambahkan hash jika diperlukan, yang sangat berguna.
Jika Anda menggunakan Webpack, ada halaman web-subresource-integrity yang dalam gaya Webpack sebenarnya lebih kompleks daripada yang diharapkan manusia, tetapi tampaknya berfungsi.
Bagi mereka yang menggunakan mesin templating Handlebars, tampaknya ada opsi yang tersedia untuk Anda, dan jika proses pembuatan Anda hanyalah JavaScript dasar, ada juga solusi sederhana di sana.
Jika Anda menggunakan CMS seperti WordPress, saya menemukan plugin yang tampaknya memudahkan, meskipun saya sendiri belum mencobanya. Googling untuk platform pilihan Anda sendiri dengan SRI atau Sub Resource Integrity kemungkinan akan mengarahkan Anda ke arah yang benar.
Anda pada dasarnya ingin mengaitkan hashing Anda setelah file JavaScript Anda diperkecil dan kemudian membuat hash itu tersedia dalam beberapa cara ke bagian mana pun dari sistem Anda yang mengeluarkan tag <script> . Salah satu keajaiban platform web adalah sangat beragam secara teknis, tetapi sayangnya saya tidak dapat memberi Anda petunjuk implementasi yang baik!
Hal lain yang perlu diperhatikan
Dalam artikel ini, saya telah berbicara banyak tentang file JavaScript karena di situlah yang paling masuk akal untuk mempertahankan diri dari serangan peretasan. SRI juga berfungsi dengan CSS, sehingga Anda dapat menggunakannya dengan cara yang persis sama di sana. Risiko untuk CSS berbahaya jauh lebih rendah, tetapi potensi untuk merusak situs masih ada dan siapa yang tahu bug browser apa yang juga dapat menyebabkan CSS secara tidak sengaja mengekspos situs Anda ke peretas. Jadi itu berfungsi menggunakan SRI di sana juga.
Hal menarik lainnya yang dapat Anda lakukan adalah menggunakan Kebijakan Keamanan Konten untuk menetapkan bahwa skrip (atau gaya) apa pun di halaman Anda harus menggunakan SRI, dan tentu saja SRI tersebut harus divalidasi.
Content-Security-Policy: require-sri-for script;Ini adalah cara untuk memastikan bahwa SRI selalu digunakan, yang dapat berguna di situs yang dikerjakan oleh banyak anggota tim yang mungkin atau mungkin tidak sepenuhnya memahami cara melakukan sesuatu. Sekali lagi, tempat yang baik untuk membaca lebih lanjut tentang ini adalah dokumen MDN yang selalu bagus untuk Integritas Subsumberdaya.
Hal terakhir yang layak dibicarakan adalah dukungan browser untuk SRI. Dukungan di browser modern sangat luas, dengan pengecualian utama adalah Internet Explorer. Karena cara spesifikasi yang kompatibel ke belakang telah diterapkan, bagaimanapun, aman untuk segera digunakan. Peramban yang memahami atribut integrity akan menggunakan hash dan memeriksa integritas, dan peramban lama hanya akan melanjutkan seperti biasa dan terus bekerja. Tentu saja, Anda tidak akan mendapatkan perlindungan tambahan di browser lama tersebut, tetapi Anda akan mendapatkan perlindungan tambahan di browser yang menawarkan dukungan.
Kesimpulan
Kami telah melihat tidak hanya apa yang dilakukan hash aneh dalam atribut integrity , tetapi bagaimana kami dapat menggunakannya untuk mempertahankan diri dari jenis serangan tertentu di situs web kami. Tentu saja, tidak ada satu peluru perak yang akan mempertahankan situs kami dari setiap jenis eksploitasi, tetapi Integritas Subsumberdaya adalah alat yang sangat berguna dalam rantai tersebut.
Memanfaatkan kelemahan keamanan sering kali tentang mendapatkan beberapa bagian kecil untuk berbaris. Jika A ada, dan Anda dapat mewujudkan B, maka bug di C memungkinkan D. Fitur browser seperti SRI memberi kami cara yang baik untuk mengikat sedikit lebih banyak dan berpotensi memutus rantai itu dan mencegah peretas mendapatkan apa yang mereka inginkan. Terlebih lagi, jika Anda dapat mengintegrasikannya ke dalam proses pembuatan atau CMS Anda, itu adalah sesuatu yang harus dapat Anda atur sekali dan kemudian lupakan dan itu tidak akan menyebabkan ketidaknyamanan Anda sehari-hari.
Karena itu, saya sangat merekomendasikan untuk melihat secara serius Integritas Subresource dan menerapkannya di situs Anda jika Anda bisa.