Buana Cyber Security Knowledge

Apa itu session replay attack?

Session replay attack adalah situasi ketika pihak tidak berwenang berhasil mendapatkan artefak autentikasi yang valid (misalnya cookie sesi, bearer token, atau token akses) lalu menggunakannya kembali untuk mengakses aplikasi seolah-olah ia adalah pengguna sah. Berbeda dengan serangan yang menebak password, replay attack memanfaatkan “bukti autentikasi” yang sudah benar, sehingga sering kali lebih sulit dideteksi jika sistem tidak punya kontrol anti-replay.

Istilah “replay” menekankan bahwa token yang sama dapat dipakai ulang dalam konteks yang tidak semestinya. Dampaknya bisa berupa pengambilalihan akun, transaksi tidak sah, akses data sensitif, hingga eskalasi insiden jika token memiliki hak akses tinggi.

Mengapa session replay berbahaya untuk web dan API?

Di aplikasi modern, sesi tidak hanya ada pada halaman web. Banyak arsitektur menggunakan API, aplikasi mobile, Single Page App (SPA), dan layanan pihak ketiga. Semakin banyak komponen berarti semakin banyak titik kebocoran token.

• Sulit dibedakan dari trafik normal: permintaan dengan token valid terlihat “sah” di log.
• Dapat melewati sebagian kontrol: jika MFA hanya diterapkan saat login, token hasil login bisa disalahgunakan tanpa memicu MFA lagi.
• Efek domino: token yang punya akses ke API internal atau microservices dapat memperluas dampak.
• Kerugian bisnis langsung: transaksi finansial, pengubahan alamat pengiriman, pengambilalihan email/nomor telepon, dan kebocoran PII.

Skenario umum penyebab token bisa “direplay”

Tujuan pencegahan adalah mengurangi peluang token jatuh ke tangan pihak lain, serta memastikan token yang dicuri tidak mudah dipakai ulang. Beberapa sumber risiko yang sering ditemui:

• Koneksi tidak aman: TLS tidak konsisten, downgrade, atau HSTS tidak diterapkan sehingga token bisa terekspos.
• Kebocoran di sisi klien: token disimpan di tempat yang mudah diakses skrip (misalnya localStorage untuk web) lalu dieksfiltrasi melalui celah XSS.
• Cookie tidak dikunci dengan benar: tidak memakai Secure, HttpOnly, dan SameSite yang sesuai.
• Log/telemetri terlalu verbose: token ikut terekam di URL, header, atau log aplikasi.
• Token berumur panjang: akses token atau session cookie tidak cepat kedaluwarsa dan tidak dirotasi.
• Perangkat terkompromi: malware, ekstensi browser berbahaya, atau perangkat yang dibajak dapat mencuri token.

Session replay attack prevention: prinsip inti

Strategi defensif yang kuat biasanya menggabungkan tiga pilar:

• Minimalkan peluang token bocor (transport & penyimpanan aman).
• Buat token sulit dipakai ulang (rotasi, TTL pendek, ikatan konteks, deteksi reuse).
• Deteksi dan respons cepat (monitoring anomali, pemutusan sesi, dan investigasi).

Kontrol pencegahan untuk aplikasi web (cookie-based session)

1) Wajib TLS end-to-end + HSTS

Pastikan seluruh aplikasi berjalan di HTTPS dan terapkan HSTS agar browser selalu menggunakan HTTPS. Token sesi yang melintas di HTTP atau pada konfigurasi TLS yang lemah berisiko disadap.

• Gunakan redirect HTTP ke HTTPS secara konsisten.
• Aktifkan HSTS untuk domain utama (dan subdomain jika relevan).

2) Kunci cookie sesi: Secure, HttpOnly, SameSite

Cookie sesi adalah target utama pembajakan sesi. Terapkan:

• Secure: cookie hanya dikirim lewat HTTPS.
• HttpOnly: JavaScript tidak bisa membaca cookie, menurunkan risiko pencurian via XSS.
• SameSite: kurangi risiko penyalahgunaan lintas situs. Pilih Lax atau Strict sesuai kebutuhan; gunakan None hanya jika benar-benar perlu (dan wajib Secure).

Selain itu, batasi Domain dan Path cookie agar tidak terlalu luas.

3) Rotasi session ID setelah event sensitif

Lakukan session rotation (mengganti session ID) setelah login, perubahan password, aktivasi MFA, atau perubahan profil penting. Dengan begitu, token lama menjadi tidak valid sehingga lebih sulit untuk direplay jika sempat bocor.

4) Batas waktu sesi yang ketat dan idle timeout

Rekayasa pencegahan replay sangat terbantu oleh TTL pendek. Terapkan:

• Idle timeout: sesi berakhir jika tidak ada aktivitas dalam durasi tertentu.
• Absolute timeout: sesi berakhir setelah durasi maksimum walaupun aktif.

Sesuaikan dengan profil risiko (misalnya aplikasi finansial cenderung lebih ketat dibanding portal konten).

5) Proteksi XSS sebagai prioritas anti-pencurian token

Replay sering dimulai dari token yang dicuri. Salah satu jalur pencurian paling umum adalah XSS. Terapkan kontrol:

• Validasi & encoding output (contextual output encoding).
• Kebijakan Content Security Policy (CSP) untuk menurunkan dampak injeksi skrip.
• Hindari menyimpan token sensitif di tempat yang mudah diakses JavaScript pada web, bila memungkinkan.

6) CSRF defense agar sesi tidak “disalahgunakan” lintas situs

Walau CSRF bukan replay token dalam arti sempit, dampaknya serupa: sesi pengguna dipakai untuk tindakan tanpa izin. Terapkan CSRF token, SameSite cookie yang tepat, dan validasi origin untuk request state-changing.

Kontrol pencegahan untuk API (token-based auth)

1) Gunakan token berumur pendek + refresh token yang aman

Untuk API, praktik umum adalah access token berumur pendek dan refresh token dengan proteksi lebih kuat. Access token yang cepat kedaluwarsa mengurangi jendela waktu replay.

• Batasi scope access token (least privilege).
• Simpan refresh token dengan proteksi yang sesuai platform (misalnya secure storage pada mobile).

2) Rotasi refresh token dan deteksi reuse

Implementasikan refresh token rotation: setiap kali refresh dipakai, server menerbitkan refresh token baru dan menonaktifkan yang lama. Jika token lama muncul lagi, anggap itu indikasi kompromi dan lakukan tindakan seperti revokasi sesi terkait.

3) Ikat token ke konteks (context binding) bila memungkinkan

Tujuannya membuat token yang dicuri kurang berguna di lingkungan berbeda. Contoh pendekatan defensif:

• Device binding berbasis identifier yang dilindungi (bukan sekadar user-agent yang mudah berubah), dengan pertimbangan privasi dan false positive.
• Proof-of-possession pada ekosistem tertentu (misalnya mekanisme yang mensyaratkan bukti kepemilikan kunci saat memakai token).
• mTLS untuk komunikasi service-to-service dan klien terkelola, sehingga token saja tidak cukup tanpa sertifikat klien.

Catatan penting: hindari mengunci terlalu agresif pada sinyal yang mudah berubah (IP publik, user-agent) karena dapat mengganggu pengguna sah. Gunakan sebagai sinyal risiko, bukan satu-satunya penentu.

4) Tambahkan nonce/timestamp dan verifikasi anti-replay untuk request sensitif

Untuk endpoint bernilai tinggi (transfer dana, perubahan email, pembuatan API key), pertimbangkan mekanisme anti-replay di level permintaan: server memverifikasi keunikan permintaan (misalnya nonce sekali pakai) dan menolak duplikasi dalam jendela waktu tertentu. Ini membantu mencegah pengulangan request yang sama walau token masih valid.

Deteksi dini: tanda sesi direplay

Karena request terlihat valid, Anda perlu mengandalkan deteksi anomali dan korelasi. Indikator yang berguna:

• Perubahan lokasi/perangkat mendadak yang tidak wajar untuk satu sesi.
• Concurrent session tidak lazim: sesi yang sama aktif dari dua lingkungan berbeda.
• Pola akses endpoint sensitif segera setelah login, atau pada jam yang tidak biasa.
• Refresh token reuse (jika menerapkan rotasi) adalah sinyal kompromi yang kuat.
• Kenaikan error autentikasi bersamaan dengan aktivitas sukses yang mencurigakan (indikasi brute force + token theft campuran).

Integrasikan log autentikasi, audit trail, dan event keamanan ke SIEM, lalu buat aturan alert untuk pola-pola di atas.

Respons insiden: apa yang harus dilakukan saat replay dicurigai

Session replay harus diperlakukan sebagai insiden autentikasi. Langkah defensif yang umum:

• Revoke sesi dan token terkait: paksa logout dari semua perangkat jika perlu.
• Rotasi kredensial sensitif: reset password, regen API key, dan putar secret yang mungkin terpapar.
• Naikkan friction sementara: minta re-auth dan MFA ulang untuk aktivitas berisiko.
• Analisis sumber kebocoran: periksa XSS, kebocoran log, konfigurasi cookie, atau integrasi pihak ketiga.
• Komunikasi pengguna: transparan tentang langkah mitigasi, terutama bila ada indikasi akses data.

Checklist singkat implementasi session replay attack prevention

• HTTPS + HSTS aktif di seluruh domain penting.
• Cookie sesi memakai Secure, HttpOnly, SameSite yang sesuai; scope Domain/Path minimal.
• Session ID rotation setelah login dan event sensitif.
• TTL pendek + idle timeout + absolute timeout.
• Proteksi XSS kuat (encoding output, CSP, audit dependency).
• CSRF defense untuk request state-changing.
• Access token pendek + refresh token rotation + deteksi reuse.
• Monitoring anomali dan playbook respons insiden.

FAQ

Apa perbedaan session replay attack dan session hijacking?

Session hijacking adalah istilah payung untuk pengambilalihan sesi pengguna. Session replay adalah salah satu teknik/hasilnya, yaitu ketika token atau cookie sesi yang valid dipakai ulang oleh pihak lain. Jadi replay sering menjadi mekanisme yang memungkinkan hijacking terjadi tanpa perlu mengetahui password.

Apakah MFA cukup untuk mencegah replay?

MFA sangat membantu, tetapi tidak selalu cukup jika token sesi yang dihasilkan setelah login dicuri dan masih berlaku. Karena itu, kombinasikan MFA dengan TTL token pendek, rotasi token, deteksi anomali, dan kontrol anti-XSS/anti-kebocoran agar token tidak mudah diambil.

Lebih aman simpan token di cookie atau localStorage?

Untuk aplikasi web, menyimpan sesi di cookie dengan HttpOnly umumnya lebih aman terhadap pencurian lewat JavaScript dibanding localStorage, karena localStorage dapat diakses skrip jika terjadi XSS. Namun, cookie perlu dilengkapi mitigasi CSRF (SameSite/CSRF token). Pilihan terbaik bergantung pada arsitektur, tetapi prinsipnya: minimalkan eksposur token ke JavaScript.

Bagaimana cara mengetahui token saya sedang direplay?

Tidak ada sinyal tunggal yang sempurna. Praktik efektif adalah menggabungkan beberapa indikator: reuse refresh token (jika ada rotasi), login/permintaan dari perangkat baru, sesi paralel yang tidak wajar, dan pola akses endpoint sensitif. Buat alert dan proses verifikasi, lalu lakukan revokasi sesi jika tingkat keyakinan tinggi.

Apa kontrol paling cepat yang bisa diterapkan untuk mengurangi risiko?

Prioritas cepat yang biasanya berdampak besar: pastikan HTTPS + HSTS konsisten, kunci cookie dengan Secure/HttpOnly/SameSite, pendekkan masa berlaku sesi, dan lakukan rotasi session ID setelah login. Setelah itu, lanjutkan dengan penguatan XSS, monitoring anomali, dan rotasi refresh token untuk API.