Dasar Keamanan Browser: Cara Browser Diam-Diam Melindungimu

Setiap hari kamu membuka browser dan mampir ke belasan situs berbeda, sering kali di jendela yang sama. Kamu mengecek email, membaca berita, masuk ke akun bank, lalu mungkin membuka satu link acak yang dikirim teman. Rasanya ringan dan aman-aman saja. Tapi coba pikirkan apa yang sebenarnya terjadi: kode yang ditulis oleh orang-orang asing yang tidak kamu kenal sedang diunduh ke komputermu dan langsung berjalan, otomatis, begitu halaman dimuat.

Kalau dipikir-pikir, itu seharusnya sedikit bikin waswas. Alasan kenapa hal ini biasanya tidak berujung bencana adalah karena browser bekerja sangat keras secara diam-diam, tanpa terlihat, untuk menjaga semua kode tak tepercaya itu tetap pada tempatnya. Browser bukan sekadar penampil dokumen, melainkan lebih mirip satpam teliti yang berdiri di antara kamu dan internet yang luas.

Di artikel ini kita akan menelusuri perlindungan-perlindungan utama yang diberikan browser secara cuma-cuma. Kamu tidak perlu jadi programmer untuk mengikutinya. Di akhir, kamu akan paham apa arti gembok itu sebenarnya, kenapa sebagian halaman menolak memuat konten tertentu, dan kenapa para developer diajari untuk tidak pernah percaya begitu saja pada apa yang diketik pengguna.

Browser itu penjaga, bukan sekadar jendela

Ada baiknya kita mulai dari gambaran yang tepat. Banyak orang membayangkan browser sebagai jendela: situsnya ada “di luar sana”, dan browser hanyalah kaca bening yang kamu pakai untuk melihat keluar. Gambaran itu kurang pas.

Gambaran yang lebih akurat adalah gedung berpenjaga. Situs tidak bisa langsung masuk seenaknya ke komputermu. Mereka menyerahkan kodenya ke browser, dan browser-lah yang memutuskan apa yang boleh dan tidak boleh dilakukan kode itu. Browser menjalankan kode dalam batasan ketat, mengawasi apa saja yang ia coba akses, dan memblokir apa pun yang melewati garis.

Ini penting karena web pada dasarnya dibangun di atas kebiasaan menjalankan kode milik orang lain. Saat kamu memuat sebuah halaman, browser mengunduh HTML, CSS, dan JavaScript lalu mengeksekusinya di perangkatmu. Secara teori, JavaScript itu bisa saja mencoba membaca file-mu, mengintip tab lain, atau mencuri sesi loginmu. Perlindungan-perlindungan yang kita bahas di sisa artikel ini ada justru untuk mencegah serangan “secara teori” itu benar-benar terjadi.

Same-origin policy: tiap situs tinggal di kamarnya sendiri

Aturan terpenting dalam keamanan browser adalah same-origin policy. Kalau dari seluruh artikel ini kamu hanya mengingat satu hal, jadikan ini yang itu.

Sebuah “origin” adalah gabungan dari tiga hal: skema (misalnya https), domain (misalnya acy-partner.com), dan port. Dua halaman dianggap memiliki origin yang sama hanya jika ketiganya cocok. Begini cara perbandingannya bekerja:

Halaman dasar: https://acy-partner.com/home

https://acy-partner.com/contact   → origin SAMA (skema, domain, port cocok)
https://blog.acy-partner.com/     → origin BEDA (domain berbeda)
http://acy-partner.com/home       → origin BEDA (skema beda: http vs https)
https://acy-partner.com:8443/     → origin BEDA (port berbeda)

Aturannya sendiri sederhana: kode dari satu origin tidak boleh dengan bebas membaca data dari origin lain. Skrip yang berjalan di situs-jahat.example tidak bisa menjangkau tab tempat kamu sedang login ke bank lalu membaca saldomu, cookie-mu, atau isi halamannya. Mereka disimpan di kamar terpisah, dan tembok di antaranya adalah same-origin policy.

Inilah yang membuat aman membuka tab bank di satu sisi dan situs mencurigakan di sisi lain. Tanpa aturan ini, halaman apa pun yang kamu kunjungi bisa diam-diam mengobok-obok semua situs lain tempat kamu sedang login. Konsep tetap login di banyak tab sekaligus akan jadi mimpi buruk dari sisi keamanan.

Saat situs memang perlu saling bicara

Kadang sebuah situs memang sah-sah saja perlu mengambil data dari origin lain, misalnya aplikasi web di acy-partner.com yang memanggil API di api.acy-partner.com. Secara default, same-origin policy akan memblokir itu. Jalan keluar yang terkendali adalah sebuah sistem bernama CORS (Cross-Origin Resource Sharing), di mana server secara eksplisit berkata “saya izinkan origin lain ini membaca respons saya.” Poin pentingnya untuk pemula: akses lintas-origin ditolak secara default, dan hanya dibuka dengan sengaja, oleh server, atas kemauannya sendiri. Browser tidak menelan mentah-mentah klaim sebuah situs.

Sandboxing: tiap tab dalam kotak tersegelnya sendiri

Same-origin policy menentukan apa yang boleh dilakukan kode. Sandboxing mengatur di mana kode itu boleh berjalan.

Sandbox adalah lingkungan terisolasi yang serba dikunci. Browser modern menjalankan kode situs di dalam sandbox yang sangat dibatasi: kode itu tidak bisa membaca harddisk-mu, tidak bisa menjalankan program lain, dan tidak bisa menjangkau langsung ke sistem operasimu. Ia hanya boleh melakukan sekumpulan kecil hal yang diizinkan browser, seperti menggambar halaman dan membuat permintaan jaringan sesuai aturan.

Di atas itu, browser memakai isolasi proses (process isolation). Banyak tab (dan sering kali tiap situs di dalam satu tab) berjalan sebagai proses sistem operasi yang terpisah. Bayangkan tiap tab sebagai kotak tersegelnya sendiri:

+---------------------------+   +---------------------------+
|   Tab 1: bank kamu        |   |   Tab 2: link acak        |
|   proses terisolasi       |   |   proses terisolasi       |
|   memori sendiri, sandbox |   |   memori sendiri, sandbox |
+---------------------------+   +---------------------------+
              \                           /
               \                         /
                +-----------------------+
                |   Browser-nya sendiri |
                |   mewasiti dua kotak  |
                +-----------------------+

Desain ini punya dua manfaat besar. Pertama, keamanan: kalau suatu halaman jahat entah bagaimana berhasil menembus batas normalnya, ia tetap terperangkap di dalam proses sandbox-nya sendiri dan tidak mudah menyentuh tab bank atau sistemmu. Kedua, kestabilan: kalau satu tab macet, yang ambruk hanya kotaknya sendiri, bukan seluruh browser. Kamu pasti pernah melihat satu tab menampilkan pesan error “Aw, snap” sementara yang lain tetap jalan. Itulah sandboxing yang sedang menunjukkan gunanya.

HTTPS dan gembok: dengan siapa kamu bicara, secara privat

Sejauh ini kita membahas soal mengisolasi kode. Lapisan berikutnya soal melindungi datamu saat sedang dalam perjalanan, ketika ia melintas antara perangkatmu dan situsnya.

Saat sebuah alamat web diawali https:// alih-alih http://, koneksinya dienkripsi memakai TLS. Enkripsi mengacak data sehingga siapa pun yang mengintip jaringan di tengah jalan, misalnya di Wi-Fi publik yang dipakai ramai-ramai, hanya melihat tumpukan acak tanpa arti, bukan kata sandi dan pesanmu.

HTTPS memberimu tiga hal sekaligus:

Ikon gembok kecil di address bar sebenarnya hanya berarti koneksinya terenkripsi dengan sertifikat yang valid. Itu bagus dan penting, tapi hati-hati dengan apa yang sebenarnya tidak ia janjikan.

Mixed content: kenapa halaman aman menolak bagian yang tidak aman

Begitu kamu paham HTTPS, mixed content jadi masuk akal sepenuhnya. Mixed content terjadi ketika sebuah halaman yang dimuat lewat https:// yang aman lalu mencoba menarik beberapa bagian, misalnya sebuah skrip atau gambar, lewat http:// yang tidak aman.

Ini masalah betulan, bukan cuma cari-cari kesalahan. Halamannya sendiri terlindungi, tapi penyerang di jaringan bisa mengutak-atik bagian yang tidak aman itu. Skrip yang dikirim lewat http:// polos bisa ditukar oleh penyerang dengan kode jahat, dan karena skrip itu berjalan di dalam halamanmu yang seharusnya aman, ia jadi punya akses penuh ke halaman tersebut. Satu mata rantai lemah itu meracuni seluruh halaman.

Maka browser turun tangan. Skrip dan style yang tidak aman pada halaman yang aman langsung diblokir, dan kamu mungkin melihat peringatan bahwa halaman itu “tidak sepenuhnya aman.” Memang menjengkelkan saat sesuatu tidak mau dimuat, tapi browser sedang melindungimu dari mata rantai paling lemah di dalam rantai.

https://acy-partner.com  (halaman aman)
   ├── https://.../app.js   ✓ dimuat   (aman)
   ├── https://.../logo.png ✓ dimuat   (aman)
   └── http://.../ads.js    ✗ DIBLOKIR (skrip tidak aman di halaman aman)

Solusi bagi pemilik situs sebenarnya mudah: sajikan semuanya lewat HTTPS supaya tidak ada mata rantai lemah yang bisa dimanfaatkan.

Kenapa input itu berbahaya: melongok XSS sebentar

Ada satu pertanyaan yang sering bikin pemula heran: bagaimana mungkin sekadar mengetik sesuatu bisa jadi risiko keamanan? Jawabannya adalah salah satu gagasan terpenting dalam keamanan web, dan ini menjelaskan kenapa para developer begitu hati-hati terhadap input pengguna.

Bayangkan sebuah situs dengan kotak komentar. Pengunjung biasa mengetik “Artikel yang bagus!” Tapi pengunjung jahat mengetik sesuatu yang berbeda, bukan kata-kata polos melainkan sepotong kode, berharap situsnya memperlakukan masukan itu sebagai bagian dari halaman, bukan sebagai teks.

Kalau situs menelan mentah-mentah masukan itu lalu menaruhnya langsung ke halaman, browser tidak bisa membedakan mana kode yang memang sengaja dimasukkan situs dan mana kode yang diselundupkan penyerang. Yang ia lihat hanyalah kode di halaman, lalu ia menjalankannya. Inilah inti dari serangan bernama XSS (Cross-Site Scripting): penyerang mengelabui situs tepercaya supaya situs itu mengirimkan kode si penyerang ke pengunjung lain.

Pengunjung mengetik di kotak komentar:
  Halo!  <sesuatu yang akan diperlakukan browser sebagai kode yang bisa dijalankan>

Situs naif menaruhnya langsung ke halaman  →  browser menjalankannya
  → kini ia berjalan dengan hak akses situs tepercaya, untuk tiap pengunjung

Kenapa itu begitu berbahaya? Justru karena semua yang sudah kita bahas tadi. Same-origin policy mempercayai kode berdasarkan origin-nya. Kalau kode penyerang berhasil berjalan sebagai bagian dari situs tepercaya, ia mewarisi kepercayaan situs itu dan bisa membaca cookie situs tersebut atau bertindak seolah-olah kamu. Perlindungan yang biasanya memisahkan situs jadi tidak menolong, sebab kode jahat itu kini berjalan di dalam situs yang baik.

Pertahanannya berupa satu disiplin tunggal: jangan pernah percaya input pengguna, dan selalu perlakukan ia sebagai data, bukan sebagai kode. Situs dirancang untuk “meng-escape” atau menetralkan apa pun yang dikirim pengguna supaya browser menampilkannya sebagai teks yang tak berbahaya, bukan menjalankannya. Itulah kenapa kotak komentar menampilkan kodemu sebagai karakter biasa yang kelihatan, bukan mengeksekusinya.

Ini baru pengantar yang paling lembut. XSS dan kerabat-kerabatnya adalah topik yang dalam dengan banyak variasi serta cara pertahanannya, dan semuanya termasuk dalam keamanan web sebagai bidang tersendiri yang utuh. Kita akan menggali serangan-serangan itu dan cara bertahan secara benar di artikel keamanan web khusus nanti. Untuk sekarang, intinya cukup kenapa input diperlakukan sebagai sesuatu yang berbahaya, bukan katalog lengkap tekniknya.

Merangkai semuanya

Browser melindungimu secara berlapis, dan tiap lapisan menutup celah yang berbeda:

Tidak satu pun dari ini perlu kamu nyalakan sendiri. Semuanya aktif secara default, bekerja diam-diam tiap kali kamu berselancar. Memahaminya mengubah cara kamu membaca web: kamu tahu gembok berarti “privat”, bukan “tepercaya”, kamu mengerti kenapa sebuah halaman bisa memblokir sebagian dirinya sendiri, dan kamu paham kenapa “jangan pernah percaya input pengguna” adalah aturan emas yang terus diulang para developer.

Kalau ini membangkitkan rasa penasaranmu, langkah lanjutan yang wajar adalah melihat lebih dekat bagaimana satu permintaan web sebenarnya berkelana dari browser ke server lalu kembali, dan kemudian masuk ke dunia serangan dan pertahanan web yang lebih dalam. Tapi kamu sudah memegang model dasarnya: browser adalah penjaga yang teliti, tiap situs tinggal di kamarnya sendiri, dan input tak tepercaya dianggap bersalah sampai terbukti aman.