Session adalah cara server mengingat siapa kamu di antara request. HTTP itu stateless: tiap request berdiri sendiri, server tidak otomatis tahu request ini datang dari orang yang tadi login. Bayangin penitipan jaket di kafe. Kamu titip jaket, dikasih tiket bernomor. Tiap kali mau ambil, kamu tunjukkan tiketnya, dan petugas tahu jaket mana milikmu dari nomor itu. Session ID adalah tiket itu, dan dia dititipkan di browser lewat cookie.
🧪 Tebakan cepat: login berhasil, tapi session ID-nya tetap sama persis seperti sebelum login. Serangan apa yang jadi terbuka? Tebak dulu, jawabannya ada di bagian "Fixation di Lab".
Session: tiket di antara request
Alurnya:
- Saat login, server membuat session ID acak yang panjang, lalu menyimpannya di sisi server (database atau Redis) bersama
userId-nya. - Session ID dikirim ke browser lewat cookie.
- Tiap request berikutnya, browser otomatis melampirkan cookie itu.
- Server membaca session ID, mencocokkan dengan simpanannya, dan tahu "oh, ini si User A".
Yang disimpan di cookie cuma nomor tiketnya (session ID), bukan data penting. Data aslinya ada di server.
Dua ancaman: hijacking dan fixation
- Session hijacking: penyerang mencuri session ID milik orang yang sudah login, lalu memakainya untuk berpura-pura jadi orang itu. Pencuriannya bisa lewat XSS (JavaScript membaca cookie), atau lewat jaringan kalau tidak pakai HTTPS. Inilah yang disebut session hijacking.
- Session fixation: penyerang menyodorkan session ID yang sudah dia tahu ke korban, lalu menunggu korban login dengan ID itu. Karena penyerang sudah tahu nomornya, begitu korban login, penyerang ikut masuk.
Fixation di Lab
Di Lab ada alur login dengan penyimpanan session di server. Penyerang sudah menanam session ID abc123 dan tahu nilainya. Lalu korban login. Ada satu saklar: regenerate session ID saat login.
| regenerate | Session ID setelah login | Akibat |
|---|---|---|
| mati | tetap abc123 |
ID itu kini terikat ke akun korban, dan penyerang sudah tahu abc123. Penyerang ikut masuk. |
| nyala | diganti jadi nilai acak baru | abc123 milik penyerang jadi tidak berguna, karena akun korban kini pakai ID lain. |
Jadi jawaban tebakannya: kalau session ID tidak berganti setelah login, yang terbuka adalah session fixation. Kuncinya: jangan biarkan korban login memakai session ID yang sudah ada di tangan orang lain.
Perbaikan: regenerate session ID
Selalu buat session ID baru tepat setelah login berhasil:
// PHP: bikin session ID baru, hapus yang lama
session_regenerate_id(true);
$_SESSION["userId"] = $user->id;
session_regenerate_id(true)membuat session ID baru dan menghapus yang lama. Kata yang dilengkapi di kuis adalahid. Dengan ini, ID yang mungkin sudah bocor ke penyerang langsung mati.
Session ID juga perlu dilindungi dari pencurian, dengan flag cookie:
- HttpOnly: JavaScript tidak bisa membaca cookie, jadi XSS tidak bisa mencurinya.
- Secure: cookie cuma dikirim lewat HTTPS, jadi aman dari penyadap jaringan.
- SameSite: membatasi pengiriman cookie pada request lintas situs.
(Flag cookie dibahas lebih dalam di pelajaran Cookie Security.)
Checklist session aman
- Session ID acak dan panjang (minimal 128 bit), supaya tidak bisa ditebak.
- Pasang flag HttpOnly, Secure, dan SameSite pada cookie-nya.
- Regenerate session ID setelah login.
- Terapkan timeout: idle (diam terlalu lama) dan absolute (umur maksimal).
- Invalidate session saat logout.
- Simpan session di server (database/Redis), bukan menaruh datanya di cookie.
⚠️ Jebakan yang sering ketemu
- Tidak mengganti session ID setelah login. Ini membuka session fixation. Panggil
session_regenerate_id(true)tepat setelah login sukses. - Session ID yang pendek atau mudah ditebak. Pakai generator acak yang kuat, bukan angka urut atau timestamp.
- Cookie tanpa HttpOnly. Satu celah XSS sudah cukup untuk mencuri session ID dan membajak sesi.
- Session tidak dimatikan saat logout. Logout harus benar-benar menghapus session di server, bukan cuma menghapus cookie di browser.
TL;DR: Session membuat HTTP yang stateless bisa mengingat siapa kamu, lewat session ID (tiket) yang dititipkan di cookie dan datanya disimpan di server. Dua ancaman: session hijacking (ID dicuri) dan session fixation (ID yang sudah diketahui penyerang dipakai korban login). Perbaikan utama: session_regenerate_id(true) tepat setelah login, plus cookie HttpOnly, Secure, SameSite, timeout, dan invalidate saat logout. Session ID harus acak dan panjang, dan datanya disimpan di server.
