Login Aman Bukan Hanya Soal Password: Rapikan Pengelolaan Sesi Website

Pengguna biasanya mengira keamanan login selesai setelah password berhasil diverifikasi. Padahal, setelah login, website masih harus menjaga “tanda pengenal” yang dipakai untuk mengenali pengguna pada setiap permintaan berikutnya. Tanda pengenal ini biasanya berupa session ID di dalam cookie.

Jika session ID dicuri, dipasang sebelum login, atau dibiarkan terlalu lama, penyerang tidak perlu mengetahui password untuk mengambil alih sesi. Karena itu, pengelolaan sesi perlu diperlakukan seperti kunci rumah: bukan hanya harus sulit dibuat duplikatnya, tetapi juga perlu dibatasi kapan, di mana, dan bagaimana kunci tersebut digunakan.

Memahami sesi login dengan analogi sederhana

Bayangkan Anda masuk ke sebuah gedung dan menerima kartu akses. Petugas memeriksa identitas Anda sekali, lalu kartu itu dipakai untuk membuka pintu-pintu tertentu selama Anda berada di dalam gedung.

Pada website, password digunakan saat proses autentikasi. Setelah itu, server memberikan session ID kepada browser. Browser mengirimkan ID tersebut pada permintaan berikutnya agar server tahu bahwa pengguna sudah login.

Masalah muncul ketika kartu akses itu:

• dapat dibaca oleh sembarang skrip di browser;
• masih berlaku melalui koneksi HTTP yang tidak terenkripsi;
• tidak diganti setelah pengguna berhasil login;
• diterima meskipun dibuat oleh pihak lain; atau
• tidak pernah kedaluwarsa dan tidak benar-benar dicabut saat logout.

Inilah alasan keamanan sesi tidak boleh dianggap sebagai detail kecil di balik layar.

Tiga atribut cookie yang sebaiknya menjadi standar

Untuk session cookie, tiga atribut dasar perlu diperiksa: Secure, HttpOnly, dan SameSite.

1. Secure: hanya lewat HTTPS

Atribut Secure meminta browser mengirim cookie hanya melalui koneksi HTTPS. Ini membantu mencegah session ID terlihat ketika lalu lintas jaringan disadap, terutama pada Wi-Fi publik atau jaringan yang tidak sepenuhnya dipercaya.

Namun, Secure bukan pengganti HTTPS. Website tetap perlu mengarahkan seluruh halaman ke HTTPS dan, bila sesuai dengan kondisi infrastrukturnya, menggunakan HSTS agar browser tidak kembali mencoba koneksi HTTP.

2. HttpOnly: tidak bisa dibaca JavaScript

HttpOnly mencegah cookie dibaca melalui document.cookie. Ini membatasi dampak pencurian cookie oleh sebagian skenario XSS.

Perlu dicatat, atribut ini tidak membuat XSS menjadi tidak berbahaya. JavaScript berbahaya masih dapat mengirim permintaan dari browser korban, dan browser tetap akan menyertakan cookie pada permintaan tersebut. Jadi, pencegahan XSS dan perlindungan CSRF tetap dibutuhkan.

3. SameSite: batasi pengiriman lintas situs

SameSite=Strict atau SameSite=Lax membantu membatasi kapan cookie dikirim dalam permintaan yang berasal dari situs lain. Ini menjadi lapisan pertahanan tambahan terhadap CSRF, yaitu serangan yang memanfaatkan sesi login korban untuk mengirim aksi tanpa persetujuan.

Untuk aplikasi biasa yang tidak membutuhkan alur lintas situs, Strict sering menjadi pilihan paling ketat. Jika pengguna perlu masuk dari tautan eksternal atau ada kebutuhan kompatibilitas tertentu, Lax dapat menjadi kompromi yang lebih praktis. Apa pun pilihannya, jangan mengandalkan nilai bawaan browser tanpa memeriksa perilaku aplikasi.

Jangan menerima session ID dari URL

Session ID yang muncul di URL lebih mudah bocor melalui riwayat browser, log server, bookmark, atau header referer. Contoh yang perlu dicurigai adalah alamat seperti /dashboard?session_id=abc123.

Gunakan cookie sebagai satu-satunya mekanisme pertukaran session ID. Jika aplikasi menerima ID dari URL sekaligus cookie, penyerang memiliki lebih banyak jalur untuk menyisipkan atau memaksa nilai sesi tertentu.

Gunakan juga nama cookie dan cakupan yang jelas. Untuk aplikasi yang berjalan pada satu host, pola seperti berikut dapat membantu mempersempit ruang gerak cookie:

Set-Cookie: __Host-SessionID=nilai-acak; Secure; HttpOnly; SameSite=Lax; Path=/

Prefix __Host- mensyaratkan cookie memakai HTTPS, tidak memiliki atribut Domain, dan menggunakan Path=/. Ini bukan solusi untuk semua arsitektur, tetapi berguna ketika cookie tidak perlu dibagikan ke subdomain lain.

Ganti session ID setelah login

Salah satu kesalahan penting adalah mempertahankan session ID yang sama sebelum dan sesudah autentikasi. Kondisi ini membuka peluang session fixation: penyerang lebih dulu mengetahui atau menetapkan ID sesi, lalu korban login menggunakan sesi tersebut.

Solusinya sederhana secara konsep: regenerasi session ID setelah login berhasil dan setelah terjadi perubahan hak akses. Data sesi yang sah perlu dipertahankan, tetapi pengenal sesinya harus diganti.

Contoh sederhana dalam PHP:

<?php
session_start();

// Setelah username dan password berhasil diverifikasi
session_regenerate_id(true);
$_SESSION['user_id'] = $userId;
$_SESSION['logged_in_at'] = time();
?>

Dalam aplikasi nyata, pastikan proses regenerasi tidak menyebabkan race condition atau menghapus data sesi yang masih diperlukan. Uji alur login, logout, pergantian password, dan login dari beberapa tab sebelum menerapkannya ke produksi.

Pengaturan PHP yang sering terlupakan

PHP menyediakan beberapa pengaturan yang dapat memperketat pengelolaan sesi. Salah satunya adalah session.use_strict_mode, yang membantu menolak session ID yang tidak pernah dibuat oleh server. Pengaturan cookie juga sebaiknya dipaksa dari sisi server, bukan hanya mengandalkan kode aplikasi yang mungkin tidak konsisten.

session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax

Nama konfigurasi dan dukungannya dapat berbeda menurut versi PHP serta cara deployment. Periksa dokumentasi versi PHP yang digunakan, lalu uji di staging sebelum mengubah konfigurasi produksi.

Logout harus benar-benar mengakhiri sesi

Menghapus tampilan akun dari halaman belum tentu mengakhiri sesi di server. Saat logout, hapus data sesi di server, kedaluwarsakan cookie, dan pertimbangkan untuk membersihkan cache pada halaman sensitif.

Untuk akun dengan risiko tinggi, sesi juga sebaiknya dihentikan atau diminta autentikasi ulang setelah peristiwa seperti pergantian password, perubahan alamat email, pemulihan akun, atau aktivitas dari perangkat baru yang mencurigakan.

Checklist pemeriksaan yang bisa dilakukan sekarang

1. Buka DevTools browser dan periksa cookie sesi: apakah memiliki Secure, HttpOnly, dan SameSite?
2. Pastikan session ID tidak muncul di URL, HTML, log aplikasi, atau parameter analitik.
3. Bandingkan session ID sebelum dan sesudah login. Nilainya seharusnya berubah.
4. Uji apakah tombol Back masih menampilkan data sensitif setelah logout.
5. Periksa apakah sesi lama menjadi tidak berlaku setelah password diganti.
6. Pastikan token autentikasi tidak disimpan di localStorage jika cookie HttpOnly dapat digunakan.

Keamanan sesi tidak memerlukan perubahan besar untuk mulai diperbaiki. Mulailah dari atribut cookie, regenerasi ID setelah login, strict mode PHP, dan pengujian logout. Empat langkah ini sering memberikan peningkatan nyata sebelum tim masuk ke pekerjaan yang lebih besar seperti manajemen perangkat, deteksi anomali, dan re-authentication berbasis risiko.

Sumber & bacaan lebih lanjut

• OWASP Session Management Cheat Sheet
• PHP Manual: Securing Session INI Settings
• MDN: Set-Cookie header
• OWASP Cross-Site Request Forgery Prevention Cheat Sheet

– Rio Yotto @rioyotto