FlawOpen

flawopen.com/Vulnerabilities/Session Fixation और Cookie सुरक्षा

Session Fixation: लॉगिन पर ID बदलें (CWE-384)

High Severity CWE-384 Cryptography & Auth
💡 सरल व्याख्या — चिपका हुआ सामान दावा टिकट

कल्पना करें कि किसी यात्री को सामान का ऐसा दावा नंबर इस्तेमाल करने के लिए बहकाया गया जिसे हमलावर पहले से जानता है। अगर एयरलाइन सामान जमा होने के बाद भी वही नंबर रखे, तो हमलावर बैग ले सकता है। Session Fixation में ऐप ऐसा पहचानकर्ता स्वीकार करता है जिसे हमलावर पीड़ित से इस्तेमाल करवा सकता है, और फिर बिना बदले उसे authenticated session बना देता है। दोनों शर्तें आवश्यक हैं; साधारण phishing link अकेले session fix नहीं करता, जब तक ऐप उस पहचानकर्ता को स्वीकार या सेट न कर सके।

लक्ष्य: सर्वर-साइड session प्रबंधन और authenticated browser का पहचानकर्ता।
पूर्वशर्त: हमलावर पीड़ित से ज्ञात session ID इस्तेमाल करवा सके, जैसे स्वीकार किए गए URL ID या cookie injection से।
दोष: ऐप anonymous से authenticated session में जाते समय हमलावर को ज्ञात ID बनाए रखे।
उपाय: authentication पर नई अप्रत्याशित ID दें; अलग-अलग जोखिमों के लिए cookie attributes कॉन्फ़िगर करें।

मुख्य अवधारणाएँ और subsystem शब्द

Session Fixation
Session प्रबंधन का दोष जिसमें ऐप हमलावर को ज्ञात पहचानकर्ता स्वीकार करता है और पीड़ित के login के बाद भी वही रखता है।
Session ID rotation
जब authentication session के विशेषाधिकार बढ़ाए, नई अप्रत्याशित ID जारी करें। केवल वही session data रखें जिसे ऐप को बनाए रखना है।
Cookie attributes
Secure cookie को HTTPS तक सीमित करता है; HttpOnly JavaScript से cookie पढ़ने रोकता है; SameSite कुछ cross-site cookie भेजने को नियंत्रित करता है। ये अलग जोखिमों पर काम करते हैं और ID rotation का विकल्प नहीं हैं।
__Host- prefix
समर्थित browsers में HTTPS से सेट Secure cookie, Path=/ और बिना Domain attribute की आवश्यकता होती है। इससे sibling subdomain के लिए parent domain पर उसी नाम की cookie सेट करना कठिन होता है।

चरण-दर-चरण हमले का प्रवाह

Step 1

हमलावर session ID प्राप्त करता या चुनता है

कोई अलग कमजोरी या सुविधा हमलावर को ID पाने और पीड़ित के browser से उसे भेजवाने देती है। तरीका ऐप पर निर्भर है; यदि URL में session ID स्वीकार नहीं होती तो सामान्य phishing link पर्याप्त नहीं है।

Step 2

पीड़ित हमलावर को ज्ञात पहचानकर्ता इस्तेमाल करता है

Browser वह ID ऐप को भेजता है और ऐप इसे मान्य anonymous session मानता है। हमलावर को उसी ID को पहचानने या फिर इस्तेमाल करने में सक्षम होना चाहिए।

Step 3

Authentication session के अधिकार बदलता है

पीड़ित login करता है। यदि ऐप ID बदले बिना authenticated पहचान को मौजूदा ID से जोड़ता है, तो वही ज्ञात पहचानकर्ता authenticated session दर्शाने लगता है।

Step 4

हमलावर अपरिवर्तित ID फिर इस्तेमाल करता है

यदि हमलावर ID भेज सकता है और server ने उसे अमान्य नहीं किया है, तो वह पीड़ित के session तक पहुँच सकता है। privilege बदलते समय ID rotation इस श्रृंखला को तोड़ता है।

तंत्र और मूल कारण

Session Fixation के लिए हमलावर का पीड़ित द्वारा इस्तेमाल की जाने वाली ID पर प्रभाव और login के बाद ऐप का उसे न बदलना—दोनों आवश्यक हैं। Cookie attributes अतिरिक्त सुरक्षा हैं, लेकिन rotation का विकल्प नहीं: HttpOnly script से पढ़ना सीमित करता है, Secure HTTPS लागू करता है, SameSite कुछ cross-site भेजने घटाता है और __Host- समर्थित browsers में cookie का दायरा सीमित करता है।

login_view.py (असुरक्षित पैटर्न)असुरक्षित
# 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/")
login_view.py (Django सुरक्षित उदाहरण)सुरक्षित
# 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

हमले का क्रम और वैचारिक उदाहरण

इंजीनियरिंग सुरक्षा और रोकथाम नियम

स्रोत और संबंधित सुरक्षा विषय:पूरा सुरक्षा निर्देशिका देखें →
CWE-384: Session Fixation → OWASP: Session Management Cheat Sheet → OWASP WSTG: Session Fixation परीक्षण → Django: Sessions और cycle_key() → MDN: HTTP Cookies और prefixes →