flawopen.com/Vulnerabilities/Session Fixation dan Keamanan Cookie

Session Fixation: Ganti ID saat Login (CWE-384)

Konsep inti dan istilah subsistem

Session fixation

Cacat pengelolaan sesi ketika aplikasi menerima identifier yang diketahui penyerang dan mempertahankannya setelah korban masuk.

Rotasi ID sesi

Terbitkan identifier baru yang sulit ditebak ketika autentikasi meningkatkan hak sesi. Pertahankan hanya data sesi yang memang perlu disimpan aplikasi.

Atribut cookie

Secure membatasi pengiriman cookie ke HTTPS; HttpOnly mencegah JavaScript membaca cookie; SameSite mengatur sebagian pengiriman lintas situs. Ketiganya menangani risiko berbeda dan tidak menggantikan rotasi ID.

Prefix __Host-

Pada browser yang mendukungnya, prefix ini mewajibkan cookie Secure yang disetel melalui HTTPS, memakai Path=/, dan tanpa atribut Domain. Ini membantu mencegah subdomain saudara membuat cookie bernama sama untuk domain induk.

Alur serangan langkah demi langkah

Mekanisme dan akar masalah

Session fixation memerlukan dua hal: penyerang memengaruhi identifier yang dipakai korban dan aplikasi tidak menggantinya setelah login berhasil. Atribut cookie memberi pertahanan berlapis, tetapi tidak menggantikan rotasi ID: HttpOnly membatasi pembacaan oleh skrip, Secure mewajibkan HTTPS, SameSite mengurangi sebagian pengiriman lintas situs, dan __Host- membatasi cakupan cookie di browser yang mendukungnya.

# VULNERABLE: custom session code keeps the pre-authentication ID.
def login_view(request):
    user = authenticate(request, request.POST["username"],
                        request.POST["password"])
    if user is not None:
        # BUG: privilege changes, but the session ID does not.
        request.session["user_id"] = user.pk
        request.session["authenticated"] = True
        return redirect("/account/")
    return redirect("/login/")

# HARDENED: Django login() rotates the session key on authentication.
from django.contrib.auth import authenticate, login

def login_view(request):
    user = authenticate(request, request.POST["username"],
                        request.POST["password"])
    if user is not None:
        # Uses Django's supported authentication/session integration.
        login(request, user)
        return redirect("/account/")
    return redirect("/login/")

# settings.py: use HTTPS, host-only scope, and a deliberate SameSite policy.
SESSION_COOKIE_NAME = "__Host-sessionid"
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = "Lax"
SESSION_COOKIE_PATH = "/"
SESSION_COOKIE_DOMAIN = None

Urutan serangan dan contoh konseptual

• 1Prasyarat: Kelemahan atau fitur terpisah memungkinkan penyerang memengaruhi ID yang akan dikirim browser korban.
• 2ID diketahui: Penyerang dapat mengenali atau menggunakan kembali ID sesi anonim yang sama.
• 3Autentikasi: Korban masuk sementara browser tetap mengirim ID yang diketahui.
• 4Tanpa rotasi: Aplikasi menaikkan hak sesi lama alih-alih mengganti identifier-nya.
• 5Dampak bersyarat: Penyerang hanya dapat mengakses sesi terautentikasi selama ID yang diketahui tetap valid dan dapat digunakan.

Aturan pencegahan dan penguatan engineering

• ✓Rotasi ID saat hak berubah: Terbitkan ID baru yang sulit ditebak saat login dan peningkatan hak lain; batalkan ID lama sesuai perilaku framework yang didokumentasikan.
• ✓Gunakan API autentikasi framework: Pilih integrasi login/sesi yang didukung (untuk Django, django.contrib.auth.login()) daripada menulis identitas secara manual ke sesi.
• ✓Tolak ID yang dikendalikan penyerang: Jangan menerima ID sesi dalam URL. Cegah injeksi cookie dari subdomain saudara dan uji penanganan cookie/sesi kustom.
• ✓Atur atribut cookie sesuai fungsinya: Gunakan Secure dan HttpOnly; pertimbangkan nama __Host- dengan Path=/ dan tanpa Domain. Pilih SameSite=Lax atau Strict sesuai alur login lintas situs yang sah; SameSite bukan pengganti token CSRF bila diperlukan.
• ✓Uji transisi: Dalam tes otomatis, catat ID anonim, autentikasi, pastikan ID berubah, dan konfirmasi ID lama tidak dapat membuka sesi terautentikasi.