Penulis materi, terjemahan yang kami terbitkan hari ini, mengatakan bahwa ada banyak alasan untuk mempelajari keamanan web. Misalnya, pengguna situs web yang khawatir tentang pencurian data pribadi mereka tertarik pada masalah keamanan. Keamanan menyangkut pengembang web yang berupaya meningkatkan tingkat perlindungan untuk proyek mereka. Hal yang sama dapat dikatakan tentang programmer pemula yang mencari pekerjaan dan bersiap-siap untuk wawancara. Tujuan artikel ini adalah untuk memahami beberapa teknologi keamanan web penting dalam bahasa yang dapat dimengerti. Sebelum kita mulai berbicara tentang teknologi ini, yang biasanya disebut dengan singkatan seperti CORS, CSP dan HSTS, kita akan melihat beberapa konsep keamanan dasar.
Dua konsep dasar keamanan web
Perlindungan 100% adalah mitos
Di dunia keamanan, tidak ada yang namanya "perlindungan 100% terhadap peretasan." Jika seseorang pernah memberi tahu Anda tentang tingkat perlindungan ini, ketahuilah bahwa dia salah.
▍Satu tingkat perlindungan tidak cukup
Misalkan seseorang percaya bahwa dengan mengimplementasikan CSP, ia sepenuhnya melindungi proyeknya dari serangan XSS. Mungkin seseorang menganggap bahwa perlindungan absolut tidak ada sebagai sesuatu yang diberikan, tetapi pikiran seperti yang dijelaskan di atas dapat mengunjungi siapa pun. Jika kita berbicara tentang programmer yang memutuskan untuk memahami masalah keamanan, maka mungkin alasan pemikiran semacam itu adalah kenyataan bahwa, ketika menulis kode program, mereka terutama beroperasi dengan konsep-konsep seperti "hitam" dan "putih", 1 dan 0, "benar" dan "salah". Tapi keamanannya tidak sesederhana itu.
Teknologi Keamanan Web
Mari kita mulai diskusi tentang keamanan web dengan teknologi, yang biasanya diperhatikan oleh para pengembang sejak dini, misalnya, di awal jalur profesional mereka. Omong-omong, jika Anda ingin mem-bypass metode perlindungan ini, Anda dapat menemukan banyak informasi tentang cara melakukan ini di StackOverflow. Ini tentang CORS.
▍CORS
Pernahkah Anda melihat kesalahan seperti itu:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
Menghadapi hal seperti itu, Anda berpikir bahwa Anda tentu bukan yang pertama dengan siapa ini terjadi. Googling, Anda mengetahui bahwa untuk menyelesaikan masalah ini, cukup memasang semacam ekstensi. Nah, bukankah ini luar biasa? Namun, teknologi CORS (Cross-Origin Resource Sharing, berbagi sumber daya antara berbagai sumber) tidak ada untuk mengganggu pengembang, tetapi untuk melindungi proyek mereka.
Untuk memahami bagaimana CORS melindungi proyek web, kami pertama-tama akan berbicara tentang cookie, khususnya, cookie yang digunakan untuk mengautentikasi pengguna. Cookie ini digunakan ketika bekerja dengan sumber daya web tertentu untuk memberi tahu server bahwa pengguna tersebut login. Mereka secara otomatis dikirim dengan permintaan berjalan ke server yang sesuai.
Misalkan Anda masuk ke akun Facebook Anda, dan Facebook menggunakan cookie otentikasi. Bekerja di Internet, Anda mengklik tautan
bit.ly/r43nugi , Anda diarahkan ke situs web berbahaya, katakanlah, sesuatu seperti
superevilwebsite.rocks . Skrip yang diunduh bersama dengan halaman di situs ini melakukan permintaan klien ke
facebook.com menggunakan cookie otentikasi Anda.
Di dunia tanpa CORS, skrip dari
superevilwebsite.rocks secara diam-diam dapat membuat perubahan pada profil FB Anda, dapat mencuri beberapa informasi, dengan semua konsekuensi yang terjadi kemudian. Di dunia seperti itu, "epidemi superevilwebsite.rocks" dapat dengan mudah muncul, ketika skrip yang menangkap manajemen akun pengguna menerbitkan tautan di lamannya, yang diikuti oleh teman-teman pengguna ini "terinfeksi" sendiri, dan melalui tautan yang diterbitkan di laman mereka, epidemi akhirnya mencakup semua Facebook.
Namun, di dunia di mana CORS ada, Facebook hanya akan mengizinkan permintaan untuk mengubah data akun dari
facebook.com . Dengan kata lain, administrasi situs akan membatasi pembagian sumber daya antara berbagai sumber.
Di sini Anda mungkin memiliki pertanyaan berikut: "Tetapi superevilwebsite.rocks dapat dengan mudah mengubah header sumber dalam permintaannya dan mereka akan terlihat seperti berasal dari facebook.com?"
Situs penipuan dapat mencoba melakukan ini, tetapi itu tidak akan berhasil, karena browser akan mengabaikan header seperti itu dan menggunakan data nyata.
"Bagaimana jika superevilwebsite.rocks melakukan permintaan serupa dari server?", Anda bertanya.
Dalam situasi yang sama, CORS dapat dielakkan, tetapi tidak akan ada gunanya dalam hal ini, karena, dengan mengeksekusi permintaan dari server, tidak akan mungkin untuk mengirimkan cookie otentikasi ke Facebook. Oleh karena itu, skrip, agar berhasil menyelesaikan permintaan semacam itu, harus dieksekusi di sisi klien dan memiliki akses ke cookie yang tersimpan di klien.
▍CSP
Untuk memahami apa itu CSP (Kebijakan Keamanan Konten, Kebijakan Perlindungan Konten), pertama-tama Anda perlu membicarakan salah satu kerentanan web yang paling umum. Ini tentang XSS (skrip lintas situs, skrip lintas situs).
Saat melakukan serangan XSS, penyerang menyuntikkan kode JavaScript khusus ke bagian klien dari situs tertentu. Anda mungkin berpikir: “Apa yang akan dilakukan skrip ini? Ubah warna elemen halaman? "
Misalkan seseorang berhasil menyematkan skrip JS mereka ke halaman situs yang Anda kunjungi. Apa yang bisa dilakukan skrip serupa? Faktanya, banyak hal:
- Itu dapat membuat permintaan HTTP ke situs lain, berpura-pura bahwa Anda melakukannya.
- Dia dapat mengarahkan Anda ke situs yang terlihat persis seperti tempat Anda masuk, tetapi dirancang, misalnya, untuk mencuri kredensial.
- Itu dapat menambahkan
<script> ke halaman yang berisi beberapa kode JavaScript atau dirancang untuk memuat beberapa jenis file JS. - Dia dapat menambahkan elemen
<iframe> ke halaman, yang, misalnya, akan terlihat persis seperti bidang untuk memasukkan nama dan kata sandi untuk memasuki situs. Dalam hal ini, bidang ini untuk memasukkan data tersebut akan disembunyikan.
Faktanya, kemungkinan yang terbuka bagi penyerang untuk berhasil mengeksekusi serangan XSS tidak terbatas.
Kebijakan perlindungan konten berupaya mencegahnya dengan menerapkan batasan berikut:
- Keterbatasan pada apa yang bisa dibuka di
<iframe> . - Keterbatasan pada style sheet mana yang dapat dimuat.
- Keterbatasan pada pertanyaan apa yang dapat dilakukan.
Bagaimana cara kerja CSP?
Saat Anda mengeklik tautan atau memasukkan URL situs web di bilah alamat peramban, peramban melakukan permintaan GET. Permintaan datang ke server, yang meneruskan beberapa kode HTML ke browser bersama dengan header HTTP. Jika Anda tertarik untuk melihat judul ini, buka tab Network di alat pengembang browser dan kunjungi beberapa situs. Header respons mungkin terlihat seperti ini:
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Ini adalah kebijakan keamanan konten
facebook.com . Konversikan ke tampilan yang lebih mudah dibaca:
content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
Pertimbangkan arahan CSP yang disajikan di sini:
default-src - melarang semua yang tidak diatur secara eksplisit.script-src - memperkenalkan batasan pada skrip yang dapat diunduh.style-src - memberlakukan batasan pada style sheet yang dimuat.connect-src - memperkenalkan batasan pada URL dari mana sumber daya dapat dimuat menggunakan antarmuka skrip, seperti fetch , XHR , ajax , dan sebagainya.
Perhatikan bahwa, sebenarnya, ada banyak arahan seperti itu. Browser membaca header CSP dan menerapkan aturan yang sesuai dalam file HTML yang dimuat. Arahan yang dikonfigurasi dengan benar memungkinkan hanya tindakan yang diperlukan untuk pengoperasian halaman yang benar.
Jika halaman tidak memiliki header CSP, maka tidak ada larangan berlaku untuk itu. Karakter * di header CSP adalah wildcard. Tanda seperti itu dapat diganti dengan apa saja, dan apa yang terjadi akan diizinkan.
▍HTTPS
Tentunya Anda pernah mendengar tentang HTTPS (HTTP Secure). Mungkin Anda pernah menemukan sesuatu seperti ini: "Mengapa saya harus khawatir tentang HTTPS jika saya hanya bermain game di situs?" Atau, mungkin, Anda datang dengan ide berikut: "Jika Anda tidak memiliki HTTPS, maka ini hanya gila. Di halaman 2018 tahun! Jangan percaya siapa pun yang mengatakan HTTPS dapat ditiadakan. ”
Anda mungkin pernah mendengar bahwa Chrome sekarang menandai situs sebagai tidak aman jika tidak menggunakan HTTPS.
Perbedaan utama antara HTTPS dan HTTP adalah bahwa, ketika mentransmisikan data melalui HTTPS, mereka dienkripsi, tetapi ketika mentransmisikan melalui HTTP, mereka tidak.
Mengapa perlu diperhatikan saat mentransfer data berharga? Masalahnya adalah bahwa ketika mengatur pertukaran data melalui saluran komunikasi yang tidak aman, ada kemungkinan serangan MITM (Man In The Middle, serangan perantara, atau seorang pria di serangan tengah).
Jika Anda, duduk di kafe, mengakses Internet melalui titik akses Wi-Fi terbuka, seseorang, secara sederhana, dapat berpura-pura menjadi router tempat semua permintaan dan jawaban Anda pergi. Jika data Anda tidak dienkripsi, maka perantara dapat melakukannya dengan apa pun yang diinginkannya. Katakanlah dia dapat mengedit kode HTML, CSS, atau JavaScript sebelum diterima dari server di browser Anda. Mengingat apa yang sudah kita ketahui tentang serangan XSS, Anda dapat membayangkan apa akibatnya.
"Bagaimana ini mungkin: komputer dan server saya tahu cara mengenkripsi dan mendekripsi data yang kami tukar, tetapi perantara jahat tidak?", Anda bertanya. Ini dimungkinkan berkat penggunaan protokol SSL (Lapisan Soket Aman) dan protokol TLS (Transport Layer Security) yang lebih baru. TLS menggantikan SSL pada tahun 1999 sebagai teknologi enkripsi yang digunakan dalam HTTPS. Diskusi tentang fitur TLS berada di luar cakupan artikel ini.
▍HSTS
Teknologi HSTS (HTTP Strict-Transport-Security, mekanisme aktivasi paksa koneksi aman melalui protokol HTTPS) cukup sederhana. Sebagai contoh, pertimbangkan tajuk Facebook yang sesuai lagi:
strict-transport-security: max-age=15552000; preload
Mari kita analisa:
max-age menetapkan waktu di mana browser harus memaksa pengguna untuk bekerja dengan situs web melalui HTTPS.preload - untuk keperluan kita ini tidak penting.
Header ini hanya berlaku jika Anda mengakses situs menggunakan HTTPS. Jika Anda bekerja dengan situs melalui HTTP, tajuk ini diabaikan. Alasannya cukup sederhana: Komunikasi HTTP sangat lemah sehingga header seperti itu tidak dapat dipercaya.
Mari kita gunakan lagi contoh Facebook untuk menunjukkan kegunaan praktis dari mekanisme HSTS. Misalkan Anda masuk ke facebook.com untuk pertama kalinya dan tahu bahwa HTTPS lebih aman daripada HTTP, jadi Anda menggunakan tautan ini:
https://facebook.com . Ketika browser Anda menerima kode HTML, itu juga menerima header yang memberitahu browser bahwa itu harus memaksa Anda untuk beralih ke HTTPS ketika membuat permintaan di masa depan. Setelah satu bulan, seseorang mengirimi Anda tautan HTTP ke Facebook,
http://facebook.com , dan Anda mengkliknya. Karena bulan tersebut kurang dari periode 15552000 detik yang ditentukan oleh arahan
max-age , browser akan mengirim permintaan melalui HTTPS, mencegah kemungkinan serangan MITM.
Ringkasan
Hari ini kami membahas beberapa teknologi yang secara universal digunakan untuk memastikan keamanan proyek web. Kami percaya bahwa masalah keamanan sangat penting, karena mereka benar-benar menjadi perhatian semua orang yang terhubung ke Internet. Topik keamanan web sangat besar, sehingga Anda tidak dapat mengatakan bahwa, setelah membaca beberapa artikel, seseorang akan menjadi ahli dalam bidang ini atau setidaknya belajar cukup untuk melindungi proyek web atau data pribadi Anda secara efektif. Tetapi, seperti di bidang lainnya, pengetahuan di bidang keamanan, jika ada keinginan untuk menerimanya, diakumulasikan dan kuantitasnya secara bertahap berubah menjadi kualitas. Kami berharap materi ini berkontribusi pada pengetahuan Anda tentang keamanan web.
Pembaca yang budiman! Sudahkah Anda menemui masalah keamanan yang tidak konsisten dari pengembang web?
