Hardening Browser Sandbox: Auth, Session, dan Secret per VM

Tren menjalankan browser dalam VM ringan seperti microVM membuat provisioning lebih cepat dan isolasi kernel lebih kuat dibanding proses browser biasa di host yang sama. Namun, Hardening Browser Sandbox: Auth, Session, dan Secret per VM tidak selesai di layer virtualisasi. Banyak insiden justru muncul di backend: token bocor, session pengguna tertukar, replay request, VM yang dipakai ulang tanpa pembersihan sempurna, upload file berbahaya, dan lonjakan trafik otomatis yang menghabiskan pool worker.

Jika Anda membangun layanan browser/worker ephemeral, desain yang aman biasanya membutuhkan tiga hal sejak awal: identitas VM yang kuat, session pengguna yang benar-benar terikat ke satu lifecycle, dan secret jangka pendek yang tidak hidup lebih lama dari tugasnya. Artikel ini fokus pada pola implementasi praktis di backend, bukan sekadar isolasi runtime.

Catatan konteks: banyak platform kini memakai VM ringan untuk menjalankan browser dengan startup cepat. Itu membantu containment, tetapi backend tetap menjadi titik kontrol utama untuk autentikasi, otorisasi, distribusi kredensial, dan pembatasan abuse.

Mengapa VM ringan tidak cukup tanpa hardening backend

MicroVM atau sandbox per-browser mengurangi dampak jika satu instance disusupi. Masalahnya, backend masih memegang keputusan penting: siapa boleh membuat sesi, VM mana yang menerima tugas, secret apa yang diberikan, dan kapan sebuah instance harus dihentikan. Jika keputusan ini longgar, isolasi VM bisa runtuh secara logis meskipun isolasi kernel tetap baik.

Contoh kegagalan yang sering terjadi:

Token bocor di log: token bootstrap VM atau token pengguna masuk ke access log, crash dump, atau telemetry.
Session tertukar: satu VM menerima kredensial atau cookie milik sesi lain akibat penjadwalan ulang yang tidak memeriksa binding.
Replay: request lama untuk membuat sesi atau mengambil secret diputar ulang karena backend hanya memverifikasi tanda tangan, bukan nonce dan masa berlaku.
VM reuse: instance dipakai ulang terlalu agresif sehingga file temporer, storage browser, atau state debugging terbawa ke pengguna berikutnya.
Upload file berbahaya: pengguna mengunggah dokumen yang memicu parser berisiko, zip bomb, atau payload yang mengeksploitasi alur pemrosesan.
Traffic burst otomatis: bot membuat ribuan sesi untuk menguras kuota browser, socket, dan proxy outbound.

Karena itu, model keamanan yang tepat bukan hanya browser in a VM, melainkan backend-mediated ephemeral execution: semua akses browser harus melewati backend yang menegakkan policy singkat, terikat konteks, dan dapat dicabut cepat.

Pola arsitektur yang disarankan

Komponen inti

API Gateway / Control Plane: menerima request dari client, memverifikasi auth pengguna, menerapkan rate limit, dan membuat job sesi.
Session Orchestrator: membuat record sesi, memilih host/VM, menerbitkan token singkat, dan mengatur lifecycle.
VM Manager: membuat microVM baru atau memilih VM idle sesuai policy reuse yang aman.
Secret Broker: menerbitkan secret jangka pendek untuk VM, misalnya credential akses websocket internal, URL upload terbatas, atau token ke layanan proxy.
Browser Worker di dalam VM: hanya menerima instruksi yang terikat pada session ID dan token VM yang valid.
Audit Store: menyimpan event penting secara append-only atau setidaknya immutable secara operasional.

Prinsip desain

Semua token bersifat scoped: terikat pada satu VM, satu sesi, satu tujuan, dan TTL singkat.
Jangan kirim secret permanen ke VM: VM dianggap dapat dibuang, jadi kredensial di dalamnya harus minimal dan mudah kedaluwarsa.
Session tidak boleh menjadi identitas global: session browser berbeda dari session login pengguna di aplikasi Anda.
Control plane dan data plane dipisah: pembuatan sesi, otorisasi, dan rotasi secret tidak langsung bercampur dengan streaming browser.
Default deny: VM hanya bisa berbicara ke endpoint internal yang dibutuhkan, bukan ke seluruh jaringan privat.

Alur request yang aman

Client melakukan autentikasi ke API utama.
Client memanggil endpoint create browser session dengan parameter yang tervalidasi.
Backend memverifikasi identitas pengguna, kuota, policy organisasi, dan rate limit.
Session Orchestrator membuat session record dengan status pending.
VM Manager membuat VM baru atau memilih VM idle yang lolos pemeriksaan kebersihan state.
Secret Broker menerbitkan token bootstrap VM dan token session data-plane yang berbeda fungsi.
VM melakukan attestation-lite ke control plane: mengirim VM token, nonce, dan metadata instance.
Control plane mengikat vm_id ke session_id, lalu hanya setelah itu mengeluarkan capability tambahan yang diperlukan.
Client menerima endpoint koneksi yang sudah dibatasi oleh session token singkat.
Saat sesi selesai atau timeout, backend mencabut token, menghentikan VM, dan membersihkan artefak.

Desain auth token per-VM

Mengapa token per-VM lebih aman

Tanpa token per-VM, worker dalam VM biasanya memakai credential bersama untuk mengambil job atau secret. Ini berbahaya: satu token bocor dapat dipakai untuk menyamar sebagai banyak instance. Dengan token per-VM, backend bisa membatasi dampak kebocoran ke satu lifecycle atau satu mesin virtual.

Minimal, token per-VM perlu memuat atau terikat pada:

vm_id unik
session_id jika VM hanya untuk satu sesi
aud atau tujuan penggunaan, misalnya secret-broker atau control-plane
exp singkat
jti untuk deteksi replay
boot_epoch atau penanda lifecycle untuk mencegah token lama dipakai setelah VM dibuat ulang

Jangan pakai satu token untuk semua fungsi

Pisahkan setidaknya tiga kelas token:

User session token: mewakili identitas user terhadap API produk Anda.
VM bootstrap token: dipakai sekali saat VM melakukan registrasi awal.
Data-plane/session token: dipakai client atau worker untuk koneksi WebSocket/streaming yang hanya berlaku pada satu sesi browser.

Pemisahan ini penting karena jalur eksposurnya berbeda. Token user bisa muncul di frontend; token VM ada di internal bootstrap; token data-plane sering terlihat di koneksi real-time. Jika satu token dipakai untuk semua, blast radius membesar.

Pola token yang praktis

Untuk banyak sistem, dua pendekatan realistis:

Token bertanda tangan sendiri dengan TTL singkat dan validasi lokal cepat. Cocok untuk traffic tinggi, tetapi pencabutan real-time lebih sulit jika tidak ada daftar deny atau cache jti.
Token referensi/opak yang diverifikasi ke store pusat. Cocok jika Anda butuh pencabutan cepat dan pelacakan state, dengan trade-off latensi dan ketergantungan pada backend token.

Pada layanan browser ephemeral, pendekatan hibrida sering lebih masuk akal: token bootstrap opak untuk registrasi awal, lalu capability singkat bertanda tangan untuk data-plane berlatensi rendah.

Pseudocode penerbitan token VM

function issueVmBootstrapToken(sessionId, vmId, ttlSeconds) {
  const now = unixTime();
  const payload = {
    sub: "vm-bootstrap",
    vm_id: vmId,
    session_id: sessionId,
    aud: "control-plane",
    iat: now,
    exp: now + ttlSeconds,
    jti: randomId(),
    boot_epoch: randomId()
  };

  tokenStore.put(payload.jti, {
    vm_id: vmId,
    session_id: sessionId,
    exp: payload.exp,
    used: false
  });

  return signOrEncrypt(payload);
}

function redeemVmBootstrapToken(token, nonce) {
  const claims = verify(token);
  assert(claims.aud === "control-plane");
  assert(claims.exp > unixTime());

  const record = tokenStore.get(claims.jti);
  assert(record != null);
  assert(record.used === false);

  replayStore.assertFresh(claims.jti, nonce);

  tokenStore.markUsed(claims.jti);
  return {
    vm_id: claims.vm_id,
    session_id: claims.session_id,
    boot_epoch: claims.boot_epoch
  };
}

Poin penting di sini bukan format tokennya, tetapi sekali pakai untuk bootstrap dan adanya jti + nonce agar replay lebih sulit.

Isolasi session pengguna agar tidak tertukar

Bind semua state ke session internal

Kesalahan umum adalah menganggap satu VM sama dengan satu user. Dalam praktik, Anda membutuhkan session internal yang eksplisit di database/control plane. Semua artefak harus terikat ke session ini: VM, websocket, file upload, cookie jar, trace, dan secret sementara.

Setiap request dari client atau worker sebaiknya divalidasi terhadap tuple seperti:

tenant_id
user_id
session_id
vm_id bila relevan

Jangan hanya memeriksa bahwa token valid. Pastikan token itu valid untuk resource yang sedang diakses.

Model penyimpanan state yang aman

Cookie jar per sesi: simpan terpisah secara fisik/logis, jangan dibagikan antar sesi.
Filesystem ephemeral: mount storage sementara per VM atau per sesi, lalu hapus saat selesai.
WebSocket room per sesi: namespace kanal real-time harus menyertakan session ID, bukan hanya user ID.
Artefak debugging terisolasi: screenshot, HAR, atau trace harus berada pada path/objek storage yang scoped ke tenant dan session.

Bahaya VM reuse

VM reuse dapat menghemat waktu startup, tetapi risiko kebocoran state meningkat. Bila ingin reuse, terapkan syarat minimum:

gunakan snapshot yang diketahui bersih, bukan melanjutkan disk yang sudah dipakai user lain;
hapus seluruh storage browser, unduhan, file temporer, dan cache aplikasi;
reset network namespace dan koneksi aktif;
rotasi semua secret capability;
naikkan boot_epoch agar token lama otomatis gagal.

Jika Anda belum yakin pembersihan state benar-benar konsisten, lebih aman membuat VM baru per sesi sensitif.

Distribusi secret jangka pendek

Prinsip dasar

VM sebaiknya tidak pernah menerima secret yang masa hidupnya lebih lama daripada pekerjaannya. Kalau sebuah browser hanya hidup beberapa menit, secret untuk browser itu juga sebaiknya hidup beberapa menit atau kurang.

Jenis secret yang sering dibutuhkan:

credential ke proxy outbound atau egress gateway;
URL upload hasil screenshot/video;
token akses ke websocket broker internal;
credential sementara untuk mengambil input terenkripsi atau mengirim hasil.

Pola broker secret

Alih-alih menyuntikkan semua secret saat boot, gunakan secret broker internal yang hanya melayani permintaan dari VM terdaftar dan hanya untuk secret yang sesuai policy sesi.

VM registrasi dengan bootstrap token sekali pakai.
Control plane menerbitkan capability terbatas untuk broker.
VM meminta secret spesifik berdasarkan tujuan, misalnya upload:screenshot.
Broker mengecek vm_id, session_id, tujuan, TTL, dan kuota pemakaian.
Broker mengembalikan secret singkat atau URL bertanda tangan dengan ruang lingkup sempit.

Contoh policy secret

policy vm-secret-access {
  allow purpose == "upload:screenshot"
    if session.status == "active"
    and vm.session_id == session.id
    and vm.boot_epoch == session.boot_epoch
    and ttl <= 300
    and request.count_per_minute <= 20;

  allow purpose == "proxy:egress"
    if session.network_policy == "enabled"
    and tenant.plan in ["pro", "enterprise"]
    and ttl <= 120;

  deny otherwise;
}

Pola ini bekerja karena setiap secret dikeluarkan berdasarkan tujuan yang spesifik, bukan akses umum ke semua layanan internal.

Hindari kesalahan ini

Menyimpan secret jangka panjang di image VM.
Mengirim secret lewat environment variable tanpa kontrol log dan introspeksi proses.
Mengizinkan VM mengambil secret hanya berdasarkan IP internal.
Tidak memberi TTL, sehingga secret tetap valid walaupun sesi sudah berakhir.

Validasi request pembuatan sesi

Apa yang harus divalidasi

Endpoint pembuatan sesi adalah pintu utama abuse. Validasi jangan berhenti di skema JSON. Backend perlu mengecek:

Identitas dan otorisasi user: apakah user memang boleh membuat browser session.
Kuota dan concurrency: maksimal sesi aktif per user, per tenant, per API key, dan per IP.
Parameter runtime: region, durasi, kemampuan upload/download, kebutuhan proxy, ukuran file, domain target bila ada kebijakan domain.
Idempotency: request ganda dari retry client tidak membuat dua VM untuk tugas yang sama.
Purpose binding: pastikan mode penggunaan sesuai use case yang diizinkan, misalnya automation internal vs interactive debug.

Gunakan idempotency key

Ketika client retry akibat timeout, endpoint create-session tanpa idempotency mudah membuat sesi duplikat. Simpan hasil pembuatan berdasarkan kombinasi seperti tenant_id + user_id + idempotency_key dan kembalikan sesi yang sama bila request identik masuk lagi dalam jangka wajar.

Pseudocode validasi create-session

function createBrowserSession(req) {
  const user = auth.requireUser(req);

  rateLimit.check({
    key: `create:${user.tenantId}:${user.id}`,
    burst: 5,
    windowSec: 60
  });

  const body = validateSchema(req.body, {
    mode: ["interactive", "automation"],
    ttlSec: "number",
    enableUploads: "boolean",
    targetUrl: "string?",
    idempotencyKey: "string"
  });

  assert(user.canCreateBrowserSession === true);
  assert(body.ttlSec > 0 && body.ttlSec <= MAX_SESSION_TTL);

  quota.assertWithinLimits({
    tenantId: user.tenantId,
    userId: user.id,
    requestedMode: body.mode
  });

  if (body.targetUrl) {
    policy.assertUrlAllowed(user.tenantId, body.targetUrl);
  }

  const existing = idempotencyStore.find(user.tenantId, user.id, body.idempotencyKey);
  if (existing) return existing;

  const session = sessionStore.create({
    tenantId: user.tenantId,
    userId: user.id,
    mode: body.mode,
    ttlSec: body.ttlSec,
    uploadPolicy: body.enableUploads ? "restricted" : "disabled",
    status: "pending"
  });

  enqueueProvisioning(session.id);
  idempotencyStore.save(user.tenantId, user.id, body.idempotencyKey, session);
  return session;
}

Perhatikan bahwa validasi di atas memadukan auth, policy, kuota, dan idempotency. Ini lebih efektif daripada hanya memeriksa payload.

Rate limit dan pencegahan abuse pada layanan ephemeral

Rate limit harus multi-dimensi

Satu rate limit per IP tidak cukup. Pada layanan browser/worker ephemeral, Anda sebaiknya membatasi beberapa dimensi sekaligus:

Per IP untuk meredam scanning kasar dan traffic anonim.
Per user / API key untuk mencegah pemakaian tidak wajar oleh akun valid.
Per tenant agar satu organisasi tidak mengganggu tenant lain.
Per action: create-session, upload, open-websocket, fetch-secret, start-download.
Per resource pool: total VM baru per menit, sesi aktif per region, proxy slot, bandwidth egress.

Gabungkan rate limit dengan admission control

Rate limit menahan frekuensi request, tetapi tidak menjawab kondisi kapasitas. Tambahkan admission control yang melihat pool nyata: jika stok VM atau kapasitas host menipis, backend bisa menolak sementara request baru dengan respons yang jelas, dibanding memaksa antrean tumbuh tanpa batas.

Sinyal abuse yang layak dipantau

rasio create-session tinggi tetapi sesi tidak pernah dipakai;
banyak upload gagal atau file terlalu besar berulang;
banyak token bootstrap gagal ditebus;
VM dari tenant tertentu sering meminta secret di luar tujuan normal;
lonjakan koneksi WebSocket pendek yang tidak pernah melakukan handshake penuh;
retry create-session dengan banyak idempotency key berbeda dalam waktu singkat.

Strategi mitigasi

Progressive throttling: perlambat respons sebelum memblok total.
Proof-of-work atau challenge untuk traffic anonim bila relevan.
Prepaid quota / budget enforcement pada API publik.
Warm pool terpisah per kelas tenant agar satu tenant tidak menghabiskan semua startup slot.
Circuit breaker untuk fitur mahal seperti video recording atau file scanning intensif.

Menangani ancaman nyata satu per satu

1. Token bocor

Sumber kebocoran paling umum adalah log, error tracing, header proxy, dan storage artefak debug. Mitigasi minimum:

redaksi token di semua log dan APM;
TTL pendek dan scope sempit;
pisahkan token bootstrap dari token data-plane;
simpan hash atau identifier token bila perlu audit, bukan nilai token mentah;
dukung pencabutan cepat untuk token penting.

2. Session tertukar

Ini sering berasal dari cache global, room websocket yang salah, atau scheduler yang hanya melihat VM idle tanpa memeriksa binding. Solusinya:

ikat semua resource ke session_id;
periksa tenant_id, user_id, dan session_id di setiap operasi sensitif;
jangan gunakan variabel global untuk state browser aktif;
uji race condition saat banyak sesi dibuat bersamaan.

3. Replay

Replay terjadi saat request atau token valid dipakai ulang. Cegah dengan:

jti unik dan store penggunaan;
nonce per request sensitif;
TTL singkat;
binding ke channel atau mTLS internal bila tersedia;
idempotency key pada create-session.

4. VM reuse

Bahaya utamanya adalah state tertinggal. Jika reuse diperlukan, gunakan checklist pembersihan yang bisa diuji otomatis. Bila tidak bisa dibuktikan, perlakukan reuse sebagai risiko tinggi.

5. Upload file berbahaya

Layanan browser sering perlu menerima file untuk diunggah ke situs target. Itu membuka risiko baru:

batasi ukuran, tipe, dan jumlah file;
scan file di jalur terpisah sebelum tersedia ke VM jika model bisnis memungkinkan;
jangan ekstrak arsip tanpa batasan recursion dan ukuran total;
simpan file di object storage dengan URL terbatas, bukan langsung di disk host;
jalankan parser tambahan di sandbox terpisah bila harus memproses isi file.

6. Lonjakan trafik otomatis

Serangan tidak selalu bertujuan menembus sandbox; kadang cukup menghabiskan kapasitas. Karena itu, ukur resource mahal secara eksplisit: VM start, CPU menit, bandwidth, proxy slot, storage artefak, dan durasi websocket. Abuse prevention yang baik berbicara dalam satuan kapasitas nyata, bukan hanya request per detik.

Pseudocode backend untuk binding sesi, VM, dan secret

function onVmRegister(req) {
  const { token, nonce, vmMetadata } = req.body;
  const vmClaims = redeemVmBootstrapToken(token, nonce);

  const session = sessionStore.get(vmClaims.session_id);
  assert(session.status === "pending");

  sessionStore.bindVm({
    sessionId: session.id,
    vmId: vmClaims.vm_id,
    bootEpoch: vmClaims.boot_epoch,
    vmMetadata
  });

  const streamToken = tokenIssuer.issue({
    sub: "browser-stream",
    session_id: session.id,
    vm_id: vmClaims.vm_id,
    aud: "data-plane",
    exp: unixTime() + 300,
    jti: randomId()
  });

  sessionStore.markActive(session.id);
  return { ok: true, streamToken };
}

function issueScopedSecret(req) {
  const caller = auth.requireVmCapability(req);
  const { purpose } = req.body;

  const session = sessionStore.get(caller.session_id);
  assert(session.status === "active");
  assert(session.vmId === caller.vm_id);
  assert(session.bootEpoch === caller.boot_epoch);

  abuseGuard.checkVmSecretRate(caller.vm_id, purpose);
  policy.assertVmMayAccessPurpose(session, purpose);

  return secretBroker.issue({
    sessionId: session.id,
    vmId: caller.vm_id,
    purpose,
    ttlSec: purpose === "upload:screenshot" ? 120 : 60
  });
}

function onSessionTerminate(sessionId) {
  const session = sessionStore.get(sessionId);
  tokenIssuer.revokeBySession(session.id);
  secretBroker.revokeBySession(session.id);
  vmManager.destroy(session.vmId);
  artifactStore.scheduleCleanup(session.id);
  sessionStore.markClosed(session.id);
}

Hal yang membuat pola ini kuat adalah setiap langkah menegakkan kembali hubungan session_id ↔ vm_id ↔ boot_epoch. Itu membantu mencegah token lama dipakai pada VM baru atau secret dipinjam lintas sesi.

Checklist implementasi hardening

Auth dan token

Token bootstrap VM sekali pakai.
Token data-plane terpisah dari token user.
Semua token punya TTL pendek, aud, dan jti.
Dukungan revocation untuk token berisiko tinggi.
Redaksi token di log, tracing, dan dashboard.

Session dan lifecycle

Setiap browser run memiliki session_id internal.
Semua resource di-bind ke tenant, user, session, dan bila perlu VM.
Status sesi jelas: pending, active, closing, closed, failed.
Timeout idle dan hard TTL diterapkan di control plane, bukan hanya di worker.
Termination selalu mencabut token dan membersihkan artefak.

Secret

Tidak ada secret jangka panjang di image VM.
Gunakan secret broker untuk capability bertujuan spesifik.
Secret terikat pada session_id, vm_id, dan TTL.
Batasi jumlah penerbitan secret per VM per menit.

Abuse prevention

Rate limit per IP, user, tenant, action, dan resource pool.
Admission control saat kapasitas menipis.
Idempotency key untuk create-session.
Deteksi pola create-session tanpa penggunaan lanjutan.
Kebijakan kuota per paket/tenant yang tegas.

Storage dan file

Upload dibatasi ukuran, tipe, dan jumlah.
Gunakan object storage scoped, bukan path host bersama.
Hapus download, cache, dan temp file saat sesi selesai.
Jangan percaya nama file atau MIME type dari client tanpa verifikasi tambahan.

Observability dan audit

Log event keamanan: create-session, bind VM, issue secret, revoke token, terminate.
Simpan correlation ID lintas API, orchestrator, dan worker.
Alert untuk replay, bootstrap failure berulang, dan lonjakan create-session.
Pastikan telemetry tidak menyimpan cookie, auth header, atau token mentah.

Debugging dan kesalahan yang paling sering muncul

Token valid tetapi request ditolak

Biasanya bukan masalah signature, melainkan binding. Periksa apakah aud, session_id, vm_id, dan boot_epoch masih cocok. Banyak tim hanya melihat status “token verified” lalu melewatkan validasi konteks.

Session tampak aktif, tetapi websocket gagal

Sering terjadi karena token data-plane kedaluwarsa lebih cepat daripada UI memperkirakan, atau control plane menandai sesi aktif sebelum VM registrasi penuh. Pastikan transisi status terjadi setelah binding VM sukses.

Reuse VM menyebabkan data user lama muncul

Ini tanda pembersihan state tidak lengkap. Audit browser profile directory, temp directory, shared memory, artifact path, dan cache proxy. Kalau Anda tidak bisa menulis tes otomatis yang membuktikan semuanya bersih, matikan reuse untuk mode sensitif.

Rate limit tidak efektif

Biasanya karena pembatasan hanya ada di API publik, sementara endpoint internal seperti secret broker atau websocket upgrade tidak dibatasi. Serangan akan mencari jalur termurah; semua action mahal harus punya guard sendiri.

Penutup

Hardening Browser Sandbox: Auth, Session, dan Secret per VM berarti menganggap VM ringan sebagai boundary eksekusi, bukan sebagai pengganti kontrol backend. Isolasi yang baik lahir dari kombinasi token per-VM, session yang benar-benar terikat lifecycle, secret jangka pendek berbasis tujuan, validasi create-session yang ketat, dan pembatasan abuse yang berbicara dalam kapasitas nyata.

Jika harus memilih prioritas implementasi, mulai dari lima hal ini: token bootstrap sekali pakai, binding session ke VM, secret broker bertujuan spesifik, idempotency + rate limit pada create-session, dan cleanup lifecycle yang dapat diuji. Dengan itu, backend Anda jauh lebih siap menghadapi token bocor, replay, session tertukar, VM reuse, upload berbahaya, dan spike otomatis pada layanan browser ephemeral.

Quick Search

shopping_cart Keranjang