Keamanan login tidak hanya ditentukan oleh kuat atau lemahnya password. Setelah pengguna berhasil masuk, website biasanya memberikan session ID—sebuah tanda pengenal sementara yang dipakai server untuk mengenali pengguna di setiap permintaan berikutnya. Jika tanda pengenal ini dapat dipaksakan atau dipakai ulang oleh pihak lain, akun bisa diambil alih meskipun password tidak pernah diketahui.
Jenis masalah ini dikenal sebagai session fixation. Namanya mungkin terdengar teknis, tetapi idenya sederhana: penyerang mencoba membuat korban memakai ID sesi yang sudah diketahui penyerang. Ketika korban login, ID tersebut tetap aktif dan kemudian dapat digunakan untuk mengakses sesi korban.
Bagaimana session fixation terjadi?
Bayangkan sebuah hotel memberikan nomor kamar kepada tamu. Sebelum tamu datang, seseorang sudah mengetahui nomor kamar itu dan berhasil membuat tamu memakai kamar tersebut. Jika nomor kamar tidak diganti setelah proses check-in, orang tadi berpotensi menyalahgunakan informasi yang sudah dimilikinya.
Pada website, “nomor kamar” itu adalah session ID. Skenario sederhananya seperti ini:
- Penyerang mendapatkan atau membuat session ID yang valid.
- Penyerang membujuk korban membuka URL, halaman, atau alur tertentu yang menggunakan ID sesi tersebut.
- Korban memasukkan username dan password lalu berhasil login.
- Server tidak mengganti session ID setelah login.
- Penyerang memakai ID sesi yang sama untuk mengakses akun korban.
Serangan seperti ini tidak selalu terlihat dramatis. Tidak ada halaman login palsu yang jelas, tidak ada password yang harus dicuri, dan korban mungkin tidak melihat gejala apa pun. Karena itu, pemeriksaan terhadap siklus hidup sesi perlu menjadi bagian dari pengujian keamanan aplikasi.
Masalah utamanya bukan cookie semata
Cookie memang sering menjadi tempat penyimpanan session ID, tetapi akar masalahnya adalah perilaku server saat membuat dan mempertahankan sesi. Mengaktifkan HTTPS saja belum cukup jika aplikasi tetap menggunakan ID sesi yang sama sebelum dan sesudah login.
Begitu status pengguna berubah dari “belum login” menjadi “sudah login”, identitas sesi sebaiknya diperbarui. Dalam PHP, fungsi yang umum digunakan adalah session_regenerate_id().
<?php
session_start();
if ($loginBerhasil) {
session_regenerate_id(true);
$_SESSION['user_id'] = $user['id'];
$_SESSION['login_time'] = time();
}
?>Parameter true meminta PHP menghapus data sesi lama. Implementasi nyata tetap perlu disesuaikan dengan arsitektur aplikasi, mekanisme penyimpanan sesi, dan kemungkinan adanya beberapa request yang berjalan bersamaan. Namun prinsipnya jelas: regenerasi session ID setelah autentikasi berhasil, bukan hanya saat sesi pertama kali dibuat.
Waktu penting untuk mengganti session ID
Login bukan satu-satunya momen yang perlu diperhatikan. Session ID juga sebaiknya dipertimbangkan untuk diganti ketika terjadi perubahan hak akses atau identitas pengguna, misalnya:
- Pengguna berhasil login.
- Pengguna berpindah dari akun biasa ke mode administrator.
- Pengguna melakukan proses login ulang untuk tindakan sensitif.
- Akun mendapatkan perubahan peran atau izin penting.
- Sesi dipulihkan setelah proses autentikasi tambahan.
Tujuannya adalah mencegah sesi lama dengan tingkat kepercayaan lebih rendah terus dipakai setelah status pengguna meningkat. Ini merupakan lapisan perlindungan tambahan, bukan pengganti autentikasi multifaktor atau kontrol akses yang benar.
Cookie sesi juga harus dikonfigurasi dengan benar
Regenerasi ID sesi perlu dilengkapi pengaturan cookie yang aman. Tiga atribut penting adalah Secure, HttpOnly, dan SameSite.
- Secure memastikan cookie hanya dikirim melalui koneksi HTTPS.
- HttpOnly mencegah JavaScript membaca cookie secara langsung. Ini membantu mengurangi dampak pencurian cookie melalui XSS, meskipun tidak memperbaiki akar masalah XSS.
- SameSite mengatur kapan cookie boleh ikut dikirim pada permintaan lintas situs, sehingga dapat membantu mengurangi risiko serangan tertentu seperti CSRF.
Contoh konfigurasi dasar di PHP:
<?php
session_set_cookie_params([
'secure' => true,
'httponly' => true,
'samesite' => 'Lax'
]);
session_start();
?>Nilai SameSite perlu dipilih berdasarkan kebutuhan aplikasi. Situs yang memiliki alur login atau integrasi lintas domain mungkin memerlukan konfigurasi berbeda. Yang penting, keputusan tersebut dibuat dengan sadar, bukan dibiarkan pada nilai bawaan tanpa pemeriksaan.
Jangan lupa proses logout
Logout yang hanya menghapus tampilan akun dari browser belum tentu mengakhiri sesi di server. Aplikasi sebaiknya menghapus data sesi dan membuat cookie sesi tidak lagi berlaku.
<?php
session_start();
$_SESSION = [];
if (ini_get('session.use_cookies')) {
$params = session_get_cookie_params();
setcookie(
session_name(),
'',
time() - 42000,
$params['path'],
$params['domain'],
$params['secure'],
$params['httponly']
);
}
session_destroy();
?>Untuk aplikasi yang memakai penyimpanan sesi terpusat atau sistem token, proses invalidasi perlu mengikuti mekanisme yang digunakan. Prinsipnya tetap sama: sesi lama tidak boleh terus dianggap sah setelah pengguna logout.
Bagaimana dengan WordPress?
Pengelola WordPress biasanya tidak perlu menulis ulang sistem sesi inti. Namun, risiko dapat muncul dari plugin atau tema yang membuat mekanisme login sendiri, menyimpan token di cookie, atau mengelola endpoint AJAX tanpa validasi yang memadai.
Beberapa langkah yang masuk akal:
- Gunakan WordPress, plugin, dan tema dari sumber tepercaya serta perbarui secara rutin.
- Hindari plugin yang membuat sistem autentikasi sendiri tanpa dokumentasi keamanan yang jelas.
- Periksa apakah proses login kustom mengganti token atau sesi setelah autentikasi.
- Pastikan endpoint sensitif memeriksa kemampuan pengguna, bukan hanya keberadaan cookie.
- Gunakan HTTPS penuh, termasuk pada halaman login dan area administrasi.
Jika sebuah plugin memiliki login khusus untuk pelanggan, anggota, atau vendor, alur tersebut perlu diuji seperti aplikasi login biasa. Jangan berasumsi bahwa keamanan WordPress inti otomatis melindungi seluruh logika tambahan yang dibuat plugin.
Yang bisa dilakukan sekarang
Mulailah dengan pengujian sederhana di lingkungan staging. Catat session ID sebelum login, lakukan login, lalu periksa apakah ID berubah. Ulangi pengujian ketika pengguna logout, berganti peran, dan login ulang.
Selanjutnya, periksa cookie melalui alat pengembang browser. Pastikan cookie sesi memiliki atribut Secure, HttpOnly, dan konfigurasi SameSite yang sesuai. Tinjau juga log autentikasi untuk mencari sesi yang dipakai dari lokasi, perangkat, atau pola waktu yang tidak wajar.
Session fixation bukan celah yang selalu mudah dieksploitasi, tetapi pencegahannya relatif murah dibandingkan biaya pemulihan akun yang diambil alih. Dengan mengganti session ID setelah login, mengamankan cookie, dan menguji alur autentikasi secara rutin, website memiliki fondasi yang jauh lebih kuat untuk melindungi sesi pengguna.
– Rio Yotto @rioyotto