Session Fixation چیست؟ تفاوت آن با Session Hijacking و روش‌های جلوگیری

Session Fixation یا «تثبیت نشست» نوعی آسیب‌پذیری در مدیریت Session است که در آن مهاجم تلاش می‌کند قربانی را وادار کند با یک Session ID از پیش شناخته‌شده وارد حساب خود شود. اگر وب‌سایت پس از احراز هویت، شناسه نشست را تغییر ندهد، همان Session ID از حالت ناشناس به یک Session احراز هویت‌شده تبدیل می‌شود و فردی که آن شناسه را از قبل می‌شناسد ممکن است بتواند از نشست کاربر سوءاستفاده کند.

تفاوت اصلی Session Fixation با Session Hijacking در زمان و نحوه دسترسی مهاجم به Session ID است. در Session Fixation مهاجم پیش از ورود قربانی، یک Session ID مشخص را در اختیار یا مرورگر او قرار می‌دهد و منتظر می‌ماند تا قربانی با همان نشست Login کند. اما در Session Hijacking مهاجم معمولاً تلاش می‌کند Session ID یک نشست معتبر و از قبل احراز هویت‌شده را سرقت یا تصاحب کند.

به همین دلیل یکی از مهم‌ترین اصول امنیت Session این است که وب‌سایت پس از Login، تغییر Role، ارتقای سطح دسترسی یا سایر رویدادهای امنیتی، Session ID قبلی را معتبر نگه ندارد و یک شناسه جدید و غیرقابل پیش‌بینی ایجاد کند.

Session Fixation شاید در مقایسه با XSS، SQL Injection یا CSRF کمتر شناخته شده باشد، اما ضعف در مدیریت نشست می‌تواند مستقیماً به تصاحب حساب کاربری منجر شود. اهمیت موضوع زمانی بیشتر می‌شود که Session در یک وب‌سایت وظیفه نگهداری وضعیت Authentication، سبد خرید، Permissionها، اطلاعات حساب یا عملیات مدیریتی را برعهده داشته باشد.

در این مقاله از رخنه‌کاو بررسی می‌کنیم Session Fixation چیست، Session چگونه کار می‌کند، این آسیب‌پذیری چگونه شکل می‌گیرد، چه تفاوتی با Session Hijacking دارد و برای جلوگیری از آن چه کنترل‌هایی باید در سطح Application، Cookie، Framework و زیرساخت اعمال شوند.

Session چیست؟

پروتکل HTTP ذاتاً Stateless است؛ یعنی هر Request به‌صورت مستقل پردازش می‌شود و سرور به‌صورت ذاتی نمی‌داند Request فعلی متعلق به همان کاربری است که چند ثانیه قبل وارد حساب شده است.

برای ایجاد تجربه‌ای مانند:

ورود به حساب،

سبد خرید،

پنل مدیریت،

تنظیمات شخصی،

پرداخت،

یا مشاهده اطلاعات خصوصی،

وب‌سایت باید بتواند Requestهای مختلف یک کاربر را به یک وضعیت مشترک متصل کند.

یکی از روش‌های رایج استفاده از Session است.

در یک مدل ساده، پس از ایجاد Session، سرور یک شناسه مانند Session ID به مرورگر می‌دهد.

مرورگر در Requestهای بعدی این شناسه را برای سرور ارسال می‌کند و Backend براساس آن Session مربوطه را پیدا می‌کند.

به‌صورت مفهومی:

Browser
   ↓
Session ID = random-value
   ↓
Web Server
   ↓
Session Store
   ↓
User State

خود Session ID معمولاً نباید شامل اطلاعات حساس قابل تفسیر باشد. این مقدار بیشتر شبیه کلیدی است که به یک State در سمت Server اشاره می‌کند.

اگر این کلید در اختیار فرد غیرمجاز قرار گیرد، ممکن است سرور Requestهای او را متعلق به کاربر اصلی در نظر بگیرد.

به همین دلیل Session ID از نظر امنیتی یک Credential محسوب می‌شود.

Session ID چرا اهمیت امنیتی دارد؟

بعد از Login، Session ID می‌تواند در عمل نماینده Authentication کاربر باشد.

فرض کنید کاربر با Username، Password و 2FA وارد حساب شده است.

بعد از تکمیل Login معمولاً مرورگر در هر Request دوباره Password و کد 2FA را ارسال نمی‌کند.

در عوض Session ID ارسال می‌شود.

یعنی در بسیاری از معماری‌ها:

Valid Session ID ≈ Access to Authenticated Session

این برابری دقیق فنی نیست، اما از نظر امنیتی نشان می‌دهد چرا حفاظت از Session ID اهمیت زیادی دارد.

اگر فرد دیگری بتواند Session معتبر را در اختیار بگیرد، ممکن است بدون دانستن رمز عبور بتواند در محدوده همان نشست فعالیت کند.

به همین دلیل Session ID باید:

غیرقابل پیش‌بینی باشد،

از منبع تصادفی امن تولید شود،

در URL قرار نگیرد مگر در معماری‌های بسیار خاص و کنترل‌شده،

از طریق HTTPS منتقل شود،

با Cookieهای امن نگهداری شود،

پس از Login تغییر کند،

در Logout باطل شود،

و دارای طول عمر کنترل‌شده باشد.

Session Fixation چیست؟

در Session Fixation مشکل اصلی سرقت یک Session ID تصادفی بعد از Login نیست.

مهاجم سعی می‌کند قبل از Login یک Session ID را بشناسد یا تعیین کند و قربانی را وارد همان Session کند.

اگر Application هنگام Authentication همان شناسه را حفظ کند، اتفاقی شبیه این رخ می‌دهد:

مرحله 1:
Session = ABC123
User = Anonymous

مرحله 2:
کاربر Login می‌کند

مرحله 3:
Session = ABC123
User = Authenticated

مشکل اصلی این است که Session ID تغییر نکرده است.

اگر فرد دیگری قبلاً ABC123 را می‌دانسته باشد، اکنون Session ناشناسی که می‌شناخته به یک Session احراز هویت‌شده تبدیل شده است.

مدل امن باید به شکل دیگری باشد:

قبل از Login:
Session = ABC123
User = Anonymous

بعد از Login:
Session = X9K7M2...
User = Authenticated

ABC123 = Invalid

یعنی مرز میان Anonymous و Authenticated باید با تعویض Session ID همراه باشد.

چرا به آن Session Fixation می‌گویند؟

کلمه Fixation به این موضوع اشاره می‌کند که مهاجم تلاش می‌کند Session Identifier مورد استفاده قربانی را «ثابت» یا از قبل مشخص کند.

در بسیاری از حملات Session، مهاجم دنبال این است که Session قربانی را کشف کند.

اما در Session Fixation منطق متفاوت است:

مهاجم ابتدا Session را می‌شناسد،

سپس قربانی را وارد همان Session می‌کند،

و منتظر افزایش سطح اعتبار Session می‌ماند.

این تفاوت کوچک در ظاهر، از نظر طراحی دفاع امنیتی بسیار مهم است.

اگر تیم توسعه فقط روی جلوگیری از «سرقت Cookie» تمرکز کند، ممکن است Session Fixation همچنان امکان‌پذیر باشد.

چرخه آسیب‌پذیر Session Fixation چگونه است؟

بدون ورود به روش‌های عملی سوءاستفاده، چرخه مفهومی یک Session Fixation را می‌توان در سه مرحله توضیح داد.

مرحله اول: Session پیش از Authentication ایجاد می‌شود

کاربر هنوز Login نکرده است اما وب‌سایت برای او Session ایجاد می‌کند.

این موضوع ذاتاً مشکل امنیتی نیست.

وب‌سایت‌ها ممکن است برای کاربران ناشناس نیز Session داشته باشند تا اطلاعاتی مانند:

سبد خرید،

زبان سایت،

مرحله فرم،

یا برخی Preferenceها

را نگهداری کنند.

مشکل از جایی شروع می‌شود که Session ID ناشناس پس از Login بدون تغییر باقی بماند.

مرحله دوم: Session ID برای مهاجم شناخته‌شده است

به دلایل مختلف ممکن است یک شناسه Session پیش از Authentication برای شخص دیگری شناخته شده باشد.

در طراحی امن، دانستن Session ناشناس نباید به دسترسی بعدی به حساب کاربر منجر شود.

مرحله سوم: Session پس از Login ارتقا پیدا می‌کند

قربانی Login می‌کند.

Application به جای ساخت Session ID جدید، همان Identifier قبلی را به User احراز هویت‌شده Bind می‌کند.

در این لحظه Session Fixation به یک ضعف جدی تبدیل می‌شود.

نقطه اصلی آسیب‌پذیری کجاست؟

گاهی تصور می‌شود مشکل Session Fixation مربوط به Cookie است.

اما ریشه اصلی معمولاً در Lifecycle نشست قرار دارد.

مسئله اصلی این سؤال است:

«وقتی سطح امنیتی Session تغییر می‌کند، آیا Identifier نیز تغییر می‌کند؟»

مهم‌ترین Transition معمولاً:

Anonymous → Authenticated

است.

اما تنها Transition مهم نیست.

نمونه‌های دیگر:

Normal User → Administrator

یا:

Password-authenticated → MFA-verified

یا:

Standard Session → Elevated Privileged Session

یا:

Unverified Account → Verified Account

در هر تغییر مهم Privilege، باید بررسی شود آیا حفظ Session Identifier قبلی منطقی و امن است یا خیر.

تفاوت Session Fixation و Session Hijacking چیست؟

این دو اصطلاح گاهی به جای یکدیگر استفاده می‌شوند، اما از نظر مکانیزم متفاوت‌اند.

Session Fixation

در Session Fixation مهاجم Session Identifier را قبل از Authentication قربانی می‌شناسد.

هدف این است که قربانی با همان Session وارد حساب شود.

به شکل ساده:

شناسه شناخته‌شده
      ↓
قربانی Login می‌کند
      ↓
شناسه تغییر نمی‌کند
      ↓
Session اکنون احراز هویت شده است

Session Hijacking

در Session Hijacking معمولاً Session معتبر از قبل ایجاد و احراز هویت شده است.

مهاجم تلاش می‌کند Identifier آن Session را به دست آورد.

مدل مفهومی:

کاربر Login کرده
      ↓
Session معتبر ایجاد شده
      ↓
Session ID افشا یا سرقت می‌شود
      ↓
مهاجم از Session موجود استفاده می‌کند

تفاوت اساسی

در Session Fixation:

مهاجم Session را پیش از Login می‌شناسد.

در Session Hijacking:

مهاجم Session احراز هویت‌شده را پس از ایجاد آن به دست می‌آورد.

به زبان ساده:

Session Fixation بیشتر درباره «حفظ Identifier نامطمئن هنگام Login» است.

Session Hijacking بیشتر درباره «تصاحب Identifier معتبر» است.

جدول مقایسه Session Fixation و Session Hijacking

نکته مهم این است که کنترل‌های دفاعی این دو ضعف هم‌پوشانی دارند، اما یکسان نیستند.

آیا HTTPS جلوی Session Fixation را می‌گیرد؟

خیر.

HTTPS یکی از مهم‌ترین کنترل‌های Session Security است، اما به‌تنهایی Session Fixation را برطرف نمی‌کند.

TLS کمک می‌کند داده بین مرورگر و Server در برابر شنود و دستکاری شبکه محافظت شود.

اما اگر Application چنین رفتاری داشته باشد:

قبل Login:
SID=A

بعد Login:
SID=A

رمزگذاری Transport این خطای منطقی را اصلاح نمی‌کند.

Session Regeneration همچنان ضروری است.

در مقابل HTTPS نقش بسیار مهمی در جلوگیری از افشای Session Cookie در شبکه دارد و باید برای کل Session استفاده شود، نه فقط صفحه Login.

Session Hijacking چگونه ممکن است رخ دهد؟

برای درک تفاوت بهتر، باید بدانیم Session Hijacking چه سطح حمله‌ای دارد.

راه‌های افشای Session ممکن است شامل مواردی مانند:

XSS،

انتقال ناامن بدون HTTPS،

Logهای نامناسب،

ذخیره Token در مکان ناامن،

بدافزار سمت Client،

افشای URL،

Browser Extension مخرب،

یا Security Misconfiguration

باشند.

در تمام این موارد مهاجم دنبال Session موجود و معتبر است.

در Session Fixation چنین سرقتی ممکن است اصلاً لازم نباشد.

Session Fixation و XSS چه ارتباطی دارند؟

Cross-Site Scripting یا XSS و Session Fixation دو آسیب‌پذیری متفاوت هستند.

XSS به اجرای JavaScript یا محتوای کنترل‌شده مهاجم در Origin وب‌سایت مربوط است.

Session Fixation به Lifecycle Session ID مربوط می‌شود.

اما یک ضعف می‌تواند امکان یا شدت ضعف دیگری را افزایش دهد.

اصل دفاعی مهم این است که رفع XSS جای Session Regeneration را نمی‌گیرد.

همان‌طور که Session Regeneration نیز جای جلوگیری از XSS را نمی‌گیرد.

این همان مفهوم Defense in Depth است.

Session Fixation و CSRF چه تفاوتی دارند؟

CSRF یا Cross-Site Request Forgery زمانی رخ می‌دهد که مرورگر کاربر احراز هویت‌شده به ارسال Request ناخواسته وادار شود.

در CSRF مهاجم معمولاً لازم نیست Session Cookie قربانی را بداند.

مرورگر خودش Credential را همراه Request ارسال می‌کند.

در Session Fixation هدف این است که یک Session شناخته‌شده به نشست احراز هویت‌شده قربانی تبدیل شود.

بنابراین:

CSRF → سوءاستفاده از Session قربانی برای ارسال Request
Session Fixation → تثبیت Session شناخته‌شده پیش از Login

استفاده از CSRF Token نیز به‌تنهایی Session Fixation را رفع نمی‌کند.

مهم‌ترین راه جلوگیری: Regenerate کردن Session ID

اساسی‌ترین راهکار جلوگیری از Session Fixation، ایجاد Session ID جدید پس از Authentication است.

به شکل مفهومی:

User arrives
↓
Anonymous Session A

User logs in successfully
↓
Destroy / retire Session A identifier

Generate Session B
↓
Authenticated Session B

شناسه جدید باید توسط Server تولید شود و از Randomness امن استفاده کند.

Session قدیمی نیز نباید همچنان برای دسترسی به منابع محافظت‌شده معتبر باشد.

این اصل ساده یکی از مؤثرترین کنترل‌های مقابله با Session Fixation است.

آیا باید تمام Session قبلی حذف شود؟

لزومی ندارد تمام State کاربر از بین برود.

گاهی قبل از Login اطلاعات مفیدی در Session وجود دارد.

برای مثال:

سبد خرید،

انتخاب زبان،

صفحه بازگشت،

یا Preferenceهای غیرحساس.

Application می‌تواند State موردنیاز را به Session جدید منتقل کند، اما Identifier باید تغییر کند.

در طراحی مناسب بهتر است بین:

Session State

و

Session Identifier

تفاوت قائل شویم.

ممکن است داده لازم حفظ شود ولی کلید امنیتی Session تغییر کند.

Session ID قدیمی باید چه شود؟

صرفاً ارسال Session ID جدید به Browser کافی نیست اگر شناسه قبلی همچنان در Server معتبر بماند.

بعد از Rotation باید Session قبلی براساس معماری:

Invalidate،

Destroy،

Retire،

یا به شکل امن از Session معتبر جدا شود.

در غیر این صورت ممکن است دو Session هم‌زمان همچنان به یک Authentication State دسترسی داشته باشند.

برای عملیات حساس باید Lifecycle قبلی و جدید کاملاً مشخص باشد.

Regeneration پس از تغییر سطح دسترسی

Login تنها موقعیتی نیست که Rotation لازم دارد.

فرض کنید User معمولی وارد پنل مدیریت می‌شود و پس از تأیید مجدد Credential، Role مدیریتی فعال می‌شود.

اگر Session ID تغییر نکند، Session با سطح پایین به Session با سطح بالا تبدیل شده است.

رویکرد بهتر:

User Session
↓
Privilege Elevation
↓
Generate New Session Identifier
↓
Invalidate Old Identifier

این رویکرد اصل مرزبندی امنیتی میان Privilege Levelها را تقویت می‌کند.

تغییر رمز عبور و Session

Password Change رویداد مهم دیگری است.

بعد از تغییر Credential باید تصمیم روشنی درباره Sessionهای فعال وجود داشته باشد.

بسته به مدل امنیتی ممکن است لازم باشد:

Session فعلی Rotate شود،

Sessionهای دیگر Invalid شوند،

Tokenهای قدیمی Revoked شوند،

یا Reauthentication انجام شود.

یک Policy عمومی برای تمام سیستم‌ها وجود ندارد، اما تغییر Password نباید صرفاً یک Update Database بدون بررسی Session Lifecycle باشد.

Session پس از فعال شدن 2FA

در برخی برنامه‌ها User ابتدا Password را وارد می‌کند و سپس وارد مرحله 2FA می‌شود.

یک اشتباه معماری این است که Session در مرحله Password عملاً تمام Permissionهای نهایی را دریافت کند.

بهتر است State واضح باشد:

ANONYMOUS
↓
PASSWORD_VERIFIED
↓
MFA_VERIFIED
↓
AUTHENTICATED

Permission هر مرحله باید محدود باشد.

پس از عبور از مرحله امنیتی مهم نیز Rotation Session می‌تواند سطح دفاع را افزایش دهد.

Strict Session Management چیست؟

یکی از مفاهیم مهم امنیت Session این است که Server فقط شناسه‌هایی را بپذیرد که خودش ایجاد کرده است.

در مدل Strict، اگر Client یک Session ID ناشناخته ارائه دهد، Application نباید به‌سادگی یک Session جدید با همان مقدار ایجاد کند.

Server باید:

شناسه نامعتبر را رد کند،

Session معتبر جدید ایجاد کند،

و در صورت نیاز رویداد غیرعادی را ثبت کند.

این رفتار احتمال Session Fixation را کاهش می‌دهد.

Permissive Session Management چیست؟

در مدل Permissive ممکن است Application Session Identifier ارائه‌شده از Client را بپذیرد و بر همان اساس Session ایجاد کند.

این رفتار سطح حمله را افزایش می‌دهد.

از نظر Secure by Design بهتر است Session ID یک مقدار Server-generated باشد.

Client نباید بتواند تعیین کند شناسه امنیتی Session چه باشد.

Session ID باید چقدر تصادفی باشد؟

Session Identifier باید دارای Entropy کافی باشد.

یعنی مهاجم نباید بتواند Session ID کاربر دیگر را حدس بزند.

الگوهای ناامن شامل:

اعداد ترتیبی،

Timestamp ساده،

User ID،

Email Hash ساده،

Token کوتاه،

یا مقدار قابل پیش‌بینی

هستند.

برای مثال:

session=1001
session=1002
session=1003

یک طراحی بسیار خطرناک است.

همچنین ترکیب چند مقدار قابل حدس الزاماً Secure Random ایجاد نمی‌کند.

Session ID باید توسط CSPRNG یا Cryptographically Secure Pseudo-Random Number Generator تولید شود.

چرا نباید اطلاعات کاربر داخل Session ID باشد؟

Session ID بهتر است یک Opaque Identifier باشد.

یعنی از روی مقدار آن نتوان User ID، Role، Email یا اطلاعات تجاری را استخراج کرد.

مثلاً طراحی‌ای مانند:

admin-user-18-2026

نه تنها قابل پیش‌بینی است بلکه اطلاعات داخلی را نیز افشا می‌کند.

اطلاعات Session باید در سمت Server یا ساختار امن و طراحی‌شده نگهداری شوند.

Cookie امن برای Session چگونه باید باشد؟

بسیاری از وب‌سایت‌ها Session ID را داخل Cookie نگهداری می‌کنند.

بنابراین تنظیم صحیح Cookie اهمیت زیادی دارد.

یک Cookie Session معمولاً باید با توجه به معماری از Attributeهایی مانند:

Secure

HttpOnly

SameSite

استفاده کند.

همچنین Domain و Path باید تا حد امکان محدود باشند.

نقش Secure در Session Cookie

Attribute به نام Secure باعث می‌شود مرورگر Cookie را فقط در ارتباط امن HTTPS ارسال کند.

نمونه مفهومی:

Set-Cookie: session=...; Secure

این کنترل برای جلوگیری از ارسال Cookie روی HTTP اهمیت دارد.

اما Secure به‌تنهایی Session Fixation را رفع نمی‌کند.

Session ID همچنان باید بعد از Login تغییر کند.

نقش HttpOnly

اگر Cookie دارای HttpOnly باشد، JavaScript معمولی صفحه امکان خواندن آن از طریق APIهایی مانند document.cookie را ندارد.

این موضوع می‌تواند اثر برخی حملات XSS مرتبط با سرقت مستقیم Session Cookie را کاهش دهد.

مثلاً:

Set-Cookie: session=...; Secure; HttpOnly

با این حال HttpOnly مانع اجرای تمام عملیات XSS نمی‌شود.

اگر XSS وجود داشته باشد، Script ممکن است همچنان Requestهایی را از Origin قربانی ارسال کند.

بنابراین HttpOnly یک لایه دفاعی است، نه درمان کامل XSS یا Session Fixation.

SameSite چه کمکی می‌کند؟

SameSite مشخص می‌کند Cookie در چه شرایطی همراه Requestهای Cross-site ارسال شود.

مقادیر رایج:

Strict

Lax

None

هستند.

برای Sessionهای حساس، Lax یا Strict در صورت سازگاری با Business Flow می‌توانند سطح دفاع را افزایش دهند.

اگر SameSite=None لازم باشد، Cookie باید با Secure همراه شود.

SameSite بیشتر در کاهش برخی حملات Cross-site مانند CSRF نقش دارد و کنترل اصلی Session Fixation محسوب نمی‌شود.

Domain Attribute و خطر Scope بیش از حد

Cookie می‌تواند به یک Host خاص یا دامنه گسترده‌تری محدود شود.

اگر بدون نیاز واقعی Cookie برای تمام Subdomainها در دسترس باشد، Attack Surface افزایش پیدا می‌کند.

فرض کنید:

app.example.com
blog.example.com
legacy.example.com

همه زیر یک دامنه هستند.

اگر Session Cookie بیش از حد گسترده Scope شده باشد، ضعف در یک Subdomain ممکن است امنیت Session سرویس حساس‌تر را تحت تأثیر قرار دهد.

به همین دلیل Principle of Least Privilege برای Cookie نیز صدق می‌کند.

Domain را فقط در صورت نیاز تنظیم کنید و Scope را تا جای ممکن محدود نگه دارید.

Host-only Cookie چیست؟

اگر Cookie بدون Domain Attribute تنظیم شود، معمولاً به Host تنظیم‌کننده محدودتر خواهد بود.

در بسیاری از معماری‌ها این رفتار امن‌تر از Shared Cookie میان تمام Subdomainها است.

به‌ویژه Session Authentication نباید بی‌دلیل میان سامانه‌های مستقل به اشتراک گذاشته شود.

Path Attribute

Path مشخص می‌کند Cookie برای چه مسیرهایی ارسال شود.

با این حال Path نباید به‌عنوان یک Access Control امنیتی مستقل در نظر گرفته شود.

اگر برنامه چند Application مستقل دارد، بهتر است طراحی Domain و Session Separation به‌درستی انجام شود.

نباید به Path به‌عنوان مرز امنیتی مطلق اعتماد کرد.

Cookie Prefixها

مرورگرهای مدرن از Cookie Prefixهایی پشتیبانی می‌کنند که محدودیت‌های بیشتری به Cookie تحمیل می‌کنند.

یکی از گزینه‌های مفید برای Sessionهای Host-specific استفاده از Prefixهایی مانند:

__Host-

است، مشروط بر رعایت شرایط مربوط به Secure، Path و Domain.

هدف چنین مکانیزم‌هایی کاهش Misconfiguration Cookie است.

این کنترل همچنان مکمل Session Rotation است.

چرا Session ID در URL خطرناک است؟

در بعضی سیستم‌های قدیمی ممکن است Session ID در URL قرار گیرد:

example.com/page?session=...

این طراحی خطرناک است، زیرا URL ممکن است در مکان‌های زیادی ثبت شود:

Browser History،

Web Server Log،

Proxy Log،

Analytics،

Screenshot،

Bookmark،

یا Referer در برخی شرایط.

به همین دلیل Cookie معمولاً مکان مناسب‌تری برای Session Token است.

Session Identifier نباید در Query String یا URL منتشر شود مگر معماری کاملاً خاص و دلیل امنیتی قوی وجود داشته باشد.

Session ID در Logها

Logهای Application باید از ثبت Session ID کامل اجتناب کنند.

گاهی تیم توسعه برای Debugging تمام Headerها یا Cookieها را Log می‌کند.

این کار می‌تواند باعث شود Credentialهای نشست وارد:

Log Server،

SIEM،

APM،

Error Tracker،

یا Backup

شوند.

افراد بیشتری ممکن است به این سیستم‌ها دسترسی داشته باشند.

در صورت نیاز به Correlation بهتر است از شناسه جداگانه یا نسخه Masked/Hashed با طراحی مناسب استفاده شود.

Session ID در Error Message

هیچ دلیل معمولی وجود ندارد که Session Token در Error عمومی کاربر نمایش داده شود.

مواردی مانند:

Stack Trace،

Debug Output،

Server Error،

و Diagnostic Page

باید بررسی شوند.

Production نباید Secret یا Token حساس را نمایش دهد.

Logout امن چگونه باید کار کند؟

Logout فقط حذف Cookie از Browser نیست.

Backend نیز باید Session مربوطه را Invalid کند.

مدل نامناسب:

Browser cookie removed
Server session still valid

اگر Session ID قبلاً افشا شده باشد، حذف Cookie در Browser قربانی مهاجم را متوقف نمی‌کند.

مدل بهتر:

Logout
↓
Invalidate server-side session
↓
Expire client cookie

اگر معماری از Tokenهای Stateless استفاده می‌کند، مسئله Revocation پیچیده‌تر می‌شود و باید از ابتدا طراحی شود.

Session Timeout چیست؟

Session نباید برای همیشه معتبر بماند.

چند نوع Timeout مهم وجود دارد.

Idle Timeout

اگر کاربر مدت مشخصی هیچ فعالیتی نداشته باشد، Session منقضی می‌شود.

Absolute Timeout

حتی اگر کاربر دائماً فعال باشد، پس از مدت مشخص Session باید پایان یابد و Authentication جدید انجام شود.

Renewal Timeout

در برخی معماری‌ها Session Identifier در طول Session نیز دوره‌ای Renew می‌شود.

Timeoutها Window سوءاستفاده را محدود می‌کنند، اما جای Session Rotation پس از Login را نمی‌گیرند.

Session Fixation در سایت‌های دارای Remember Me

Remember Me یک چالش جداگانه ایجاد می‌کند.

نباید Session ID طولانی‌مدت را مستقیماً به‌عنوان Remember Me Token استفاده کرد.

معماری بهتر بین:

Session کوتاه‌مدت

و

Persistent Authentication Token

تفکیک ایجاد می‌کند.

Token دائمی نیز باید:

تصادفی،

قابل لغو،

محدود،

و در صورت استفاده Rotate شود.

بعد از بازیابی Authentication از Remember Me، بهتر است Session جدید ایجاد شود.

Session Fixation در WordPress

WordPress به‌طور پیش‌فرض از ساختار Authentication Cookie مخصوص خود استفاده می‌کند و Pluginها ممکن است Session یا Tokenهای دیگری نیز ایجاد کنند.

خطر اصلی در توسعه Plugin یا Integration سفارشی زمانی ایجاد می‌شود که توسعه‌دهنده Authentication اختصاصی پیاده‌سازی کند و Lifecycle Token را درست مدیریت نکند.

مواردی که باید بررسی شوند:

Login سفارشی،

SSO Plugin،

پنل اعضا،

REST API اختصاصی،

Magic Link،

Plugin عضویت،

سیستم Affiliate،

یا Admin Dashboard سفارشی.

نباید فرض کرد چون سایت روی WordPress اجرا می‌شود هر سیستم Session سفارشی به‌صورت خودکار امن است.

Session Fixation در PHP

در PHP استفاده از Session رایج است.

یکی از اصول مهم پس از Authentication موفق، Regenerate کردن Session Identifier است.

مفهوم کلی:

session_regenerate_id(true);

است.

استفاده دقیق از این قابلیت باید با Flow برنامه، مدیریت Session Store و شرایط Concurrency هماهنگ باشد.

پارامتر مربوط به حذف Session قدیمی نیز باید آگاهانه انتخاب شود.

مهم‌تر از Syntax این است که تیم توسعه بداند «چه زمانی» Session باید Rotate شود.

Session Fixation در Node.js

Frameworkهای Node.js نیز معمولاً Session Middleware دارند.

نکته مهم این است که بعد از Login فقط قرار دادن:

session.user = user

بدون Rotation Identifier ممکن است طراحی مطلوبی نباشد.

باید از قابلیت Regenerate Session خود Middleware یا Framework استفاده شود.

همچنین Store مشترک مانند Redis باید Lifecycle نشست را به شکل صحیح مدیریت کند.

Session Fixation در Java

Applicationهای Java و Servlet-based نیز باید پس از Authentication یا Privilege Change شناسه Session را تغییر دهند.

Frameworkهای مدرن اغلب قابلیت‌های داخلی برای Session Rotation دارند.

استفاده از Framework Security معتبر معمولاً امن‌تر از طراحی Authentication و Session Management از صفر است.

با این حال Configuration باید بررسی شود.

Session Fixation در ASP.NET

در برنامه‌های ASP.NET نیز نباید فقط به وجود Session Cookie اعتماد کرد.

Authentication Framework باید Login Transition را مدیریت کند.

اگر تیم توسعه سیستم Authentication سفارشی پیاده‌سازی کرده است، باید بررسی کند Token قبل و بعد از Login چه Lifecycleی دارد.

SSO و Session Fixation

Single Sign-On معماری Session را پیچیده‌تر می‌کند.

در این مدل ممکن است چند Session وجود داشته باشد:

Identity Provider Session

Application Session

OAuth/OIDC State

Authentication Code

Refresh Token

Access Token

هرکدام Lifecycle متفاوتی دارند.

بعد از Authentication در Identity Provider، Application مقصد باید Session محلی جدیدی ایجاد کند.

نباید Session ناشناس قدیمی بدون بررسی به سطح Authenticated ارتقا پیدا کند.

OAuth و Session Fixation یکسان نیستند

OAuth مشکلات امنیتی و State Management مخصوص خود را دارد.

نباید هر مشکلی که در Login Flow رخ می‌دهد Session Fixation نامید.

برای مثال:

ضعف state

Redirect URI ناامن

Token Leakage

و Authorization Code مشکلات متفاوتی هستند.

با این حال Applicationی که بعد از OAuth Login یک Local Session می‌سازد همچنان باید Session Lifecycle امنی داشته باشد.

آیا JWT باعث حذف Session Fixation می‌شود؟

نه لزوماً.

JWT و Session دو مفهوم دقیقاً یکسان نیستند، اما انتقال به JWT تمام مشکلات Session Management را از بین نمی‌برد.

اگر Application قبل و بعد از Login Tokenهای مختلفی دارد، Lifecycle Token همچنان اهمیت دارد.

همچنین JWT مشکلات دیگری ایجاد می‌کند:

Revocation،

Expiration،

Storage،

Refresh Token،

Key Rotation،

Audience،

Issuer،

و Token Theft.

امنیت Authentication با تغییر فرمت Token به‌صورت خودکار حل نمی‌شود.

LocalStorage یا Cookie؟

این سؤال معمولاً در کنار Session Security مطرح می‌شود.

هیچ پاسخ واحدی برای تمام معماری‌ها وجود ندارد، اما برای Sessionهای مرورگری، Cookie با تنظیمات امن مزایایی مانند HttpOnly دارد.

Token ذخیره‌شده در LocalStorage برای JavaScript قابل دسترسی است و در صورت XSS ممکن است در معرض سرقت باشد.

از طرف دیگر Cookieها نیازمند توجه جدی به CSRF هستند.

انتخاب باید براساس Threat Model انجام شود.

آیا تغییر Session ID در هر Request لازم است؟

معمولاً خیر.

Regenerate کردن Session ID در هر Request می‌تواند پیچیدگی و مشکلات Race/Concurrency ایجاد کند.

Rotation باید در نقاط امنیتی مناسب انجام شود:

Login،

Privilege Change،

Reauthentication،

رویدادهای پرخطر،

و در صورت طراحی، Renewal دوره‌ای.

هدف ایجاد Lifecycle قابل پیش‌بینی و امن است.

مشکلات Race Condition هنگام Session Regeneration

خود Session Rotation نیز اگر بد پیاده‌سازی شود ممکن است مشکل‌ساز شود.

تصور کنید Browser چند Request هم‌زمان ارسال کند و در همان لحظه Session Rotate شود.

یکی از Requestها ممکن است Session جدید و دیگری Session قدیمی را داشته باشد.

Application باید رفتار این Window را تعریف کند.

در برخی Frameworkها مکانیزم‌های داخلی این مسئله را مدیریت می‌کنند.

به همین دلیل بهتر است به جای پیاده‌سازی Session Engine اختصاصی، از Frameworkهای معتبر استفاده شود.

Session Fixation و Subdomainها

Subdomainها یکی از مهم‌ترین حوزه‌های طراحی Cookie هستند.

فرض کنید وب‌سایت اصلی:

secure.example.com

و سرویس قدیمی:

old.example.com

باشد.

اگر Authentication Cookie برای کل:

.example.com

معتبر باشد، امنیت Subdomainهای دیگر اهمیت مستقیم پیدا می‌کند.

اصل امنیتی بهتر:

Cookie Authentication را تا حد امکان Host-specific نگه دارید.

اگر اشتراک Cookie ضروری است، تمام Subdomainهای داخل Scope باید با همان حساسیت امنیتی مدیریت شوند.

چرا Session Name مهم است؟

نام Cookie امنیت را تضمین نمی‌کند.

برای مثال تغییر:

PHPSESSID

به:

super_secret_cookie

Session Fixation را حل نمی‌کند.

نام کمتر شناخته‌شده ممکن است مقدار کمی Information Disclosure را کاهش دهد، اما نباید Security Control اصلی تلقی شود.

امنیت باید بر Randomness، Rotation و Protection Token متکی باشد.

Bind کردن Session به IP خوب است؟

برخی سیستم‌ها Session را به IP Address Bind می‌کنند.

این کنترل می‌تواند در بعضی محیط‌های محدود سیگنال امنیتی ایجاد کند، اما برای وب عمومی مشکلات زیادی دارد.

IP کاربر ممکن است تغییر کند:

Mobile Network،

NAT،

VPN،

Corporate Proxy،

IPv6 Privacy Address

و سایر شرایط.

در نتیجه Hard Binding ممکن است False Positive زیادی ایجاد کند.

بهتر است IP به‌عنوان Risk Signal استفاده شود، نه الزاماً Credential اصلی Session.

Bind کردن Session به User-Agent

User-Agent نیز قابل جعل است.

Bind کامل Session به User-Agent کنترل قابل اتکای اصلی نیست.

اما تغییر ناگهانی Client Characteristics می‌تواند به Risk Engine کمک کند.

Session Security نباید به Fingerprint ساده Browser وابسته باشد.

Device Binding چیست؟

در سیستم‌های حساس‌تر می‌توان Session را به اطلاعات بیشتری از Device یا Keyهای Cryptographic متصل کرد.

این حوزه پیچیده‌تر از Cookie Session عادی است.

راهکارهایی مانند:

Device-bound Credential

Passkey

یا Token Bindingهای معماری‌شده

ممکن است در سناریوهای خاص امنیت را افزایش دهند.

اما برای جلوگیری از Session Fixation ساده، Session Regeneration همچنان کنترل اصلی است.

Reauthentication برای عملیات حساس

حتی یک Session معتبر نباید الزاماً اجازه انجام تمام عملیات حساس را بدون بررسی مجدد بدهد.

برای عملیات‌هایی مانند:

تغییر رمز عبور،

تغییر ایمیل،

فعال‌کردن API Key،

تغییر 2FA،

برداشت مالی،

یا عملیات Administrator

می‌توان Reauthentication درخواست کرد.

بعد از Reauthentication موفق، Rotation Session نیز می‌تواند منطقی باشد.

Session Fixation در سیستم‌های Multi-Tenant

در سیستم SaaS ممکن است یک User در چند Organization عضو باشد.

اگر تغییر Tenant باعث تغییر Permission قابل توجه می‌شود، Session Context باید به‌درستی Update شود.

نباید Tenant ID فقط از Request Client دریافت و بدون Authorization پذیرفته شود.

در برخی معماری‌ها تغییر Context امنیتی مهم می‌تواند نیازمند Token یا Session Rotation باشد.

مدیریت Session در Redis

بسیاری از برنامه‌ها Session را در Redis نگه می‌دارند.

Redis صرفاً Session Store است.

امنیت Session همچنان نیازمند:

Random ID،

Rotation،

TTL،

Deletion،

Authentication/Network Security Redis،

و کنترل دسترسی

است.

اگر Session قدیمی بعد از Regeneration در Redis باقی بماند و همچنان معتبر باشد، Rotation کامل انجام نشده است.

Database Session Store

اگر Sessionها داخل Database ذخیره شوند نیز همان اصول برقرار هستند.

جدول Session ممکن است شامل:

Session ID Hash،

User ID،

Created Time،

Last Activity،

Expiration،

Device Metadata،

Revocation Status

باشد.

بهتر است Session ID خام در Database در صورت امکان به‌گونه‌ای ذخیره شود که افشای Database به معنی دسترسی مستقیم به تمام Sessionها نباشد.

Hash کردن Session Token سمت Server

یک معماری قوی می‌تواند مشابه Password Reset Token عمل کند.

Client Token خام را نگه می‌دارد، اما Server تنها Hash آن را ذخیره می‌کند.

در صورت افشای Session Store، مهاجم نتواند مستقیماً از Tokenهای ذخیره‌شده استفاده کند.

این طراحی نیازمند Implementation صحیح و بررسی Performance است.

Session Enumeration چیست؟

اگر Session ID قابل پیش‌بینی باشد، مهاجم ممکن است به جای Fixation، Sessionهای دیگر را حدس بزند.

این ضعف با Session Fixation متفاوت اما مرتبط با Session Management است.

برای جلوگیری:

Session ID باید Random باشد،

فضای Token بزرگ باشد،

Rate Limit وجود داشته باشد،

و Invalid Session Patternها Monitoring شوند.

چه رویدادهایی باید باعث Invalid شدن Session شوند؟

بسته به Application، رویدادهای زیر می‌توانند Sessionها را باطل کنند:

Logout،

Password Reset،

Password Change،

Account Disable،

User Deletion،

Role Revocation،

Security Incident،

Admin Forced Logout،

Token Compromise،

یا پایان Absolute Timeout.

Policy باید شفاف و قابل تست باشد.

Logout از همه دستگاه‌ها

قابلیت «خروج از همه دستگاه‌ها» برای سیستم‌های حساس مفید است.

این قابلیت نیازمند این است که Application Sessionهای فعال کاربر را بشناسد یا مکانیزم Revocation مناسبی داشته باشد.

فقط حذف Cookie مرورگر فعلی چنین قابلیتی ایجاد نمی‌کند.

پنل Active Sessions

نمایش Sessionهای فعال به User می‌تواند امنیت حساب را افزایش دهد.

مثلاً:

زمان ایجاد،

آخرین فعالیت،

Device تقریبی،

Location تقریبی،

و امکان Logout Session

می‌تواند به شناسایی نشست مشکوک کمک کند.

باید مراقب بود اطلاعات Device و Location به شکل بیش از حد دقیق یا حساس نمایش داده نشوند.

Session Fixation را چگونه در Code Review پیدا کنیم؟

مهم‌ترین سؤال این است:

«بعد از Authentication موفق چه اتفاقی برای Session ID می‌افتد؟»

اگر پاسخ این باشد:

«همان Session قبلی فقط user_id دریافت می‌کند»

باید بررسی امنیتی جدی انجام شود.

موارد مهم Code Review

مسیر Login را پیدا کنید.

محل ایجاد Session را مشخص کنید.

بررسی کنید Session پیش از Login وجود دارد یا خیر.

بعد از Login رفتار Identifier را بررسی کنید.

مسیر Privilege Elevation را بررسی کنید.

Logout را بررسی کنید.

Password Change را بررسی کنید.

MFA Flow را بررسی کنید.

SSO Callback را بررسی کنید.

Remember Me را بررسی کنید.

تمام این Transitionها می‌توانند نقطه ضعف باشند.

تست دفاعی Session Fixation

تست امنیت باید فقط روی سامانه‌ای انجام شود که مالک آن هستید یا مجوز صریح برای بررسی آن دارید.

هدف تست دفاعی این است که مشخص شود Session Identifier در Transitionهای امنیتی تغییر می‌کند یا خیر.

در محیط Staging می‌توان رفتار Session قبل و بعد از Authentication را مقایسه کرد.

انتظار امن:

Before Login:
Session ID = A

After Login:
Session ID = B

A != B

سپس باید بررسی شود که Identifier قبلی دیگر برای منابع Authenticated معتبر نباشد.

هدف این تست حمله به حساب دیگران نیست؛ هدف تأیید Lifecycle طراحی‌شده Session است.

تست Logout

پس از Logout باید Session قبلی نامعتبر باشد.

تست دفاعی باید بررسی کند:

Browser Cookie پاک شده است؟

Server Session حذف یا Revoked شده است؟

Request با Credential قبلی Reject می‌شود؟

Session جدید در صورت بازگشت کاربر مستقل است؟

تست Privilege Change

اگر Application دارای Roleهای متفاوت است، باید Transitionها بررسی شوند.

برای مثال:

User → Admin

یا:

Authenticated → MFA Verified

Session Identifier باید مطابق Policy امنیتی Rotate شود.

Monitoring برای Session Fixation

Logging مناسب می‌تواند فعالیت‌های غیرعادی Session را آشکار کند.

Eventهای مفید:

Session Creation

Session Rotation

Authentication Success

Authentication Failure

Privilege Change

Logout

Session Revocation

Invalid Session ID

Session Reuse

اما Session ID خام نباید در Log ثبت شود.

می‌توان یک شناسه داخلی یا Hash مناسب برای Correlation استفاده کرد.

شناسایی Session قدیمی پس از Rotation

اگر Identifier قدیمی پس از Login استفاده شود، این رویداد می‌تواند Suspicious محسوب شود.

Server ممکن است:

Request را Reject کند،

Event را Log کند،

Risk Score را افزایش دهد،

و در صورت شرایط خاص Alert ایجاد کند.

البته Monitoring باید طوری طراحی شود که به دلیل Requestهای هم‌زمان عادی False Positive زیاد ایجاد نکند.

Session Anomaly Detection

سیستم‌های حساس می‌توانند Signalهایی مانند:

تغییر ناگهانی کشور،

Device متفاوت،

Impossible Travel،

تعداد Session زیاد،

Privileged Action غیرمعمول،

یا تغییر ناگهانی Network

را تحلیل کنند.

این موارد جای Authentication یا Session Rotation را نمی‌گیرند.

آن‌ها لایه مکمل Detection هستند.

اشتباهات رایج در امنیت Session

تغییر ندادن Session ID بعد از Login

مهم‌ترین خطا در Session Fixation همین است.

Anonymous Session نباید بدون Rotation تبدیل به Authenticated Session شود.

اتکا به HTTPS

HTTPS ضروری است، اما Lifecycle اشتباه Session را اصلاح نمی‌کند.

استفاده از Session ID قابل پیش‌بینی

شناسه Session باید دارای Randomness کافی باشد.

قرار دادن Session در URL

این کار احتمال Leakage را به‌شدت افزایش می‌دهد.

ثبت Cookie در Log

Credentialهای Session نباید در Logging عمومی ذخیره شوند.

استفاده از Cookie بدون Secure

Session Authentication باید روی HTTPS منتقل شود.

عدم استفاده از HttpOnly

در Session Cookieهای مرورگری، HttpOnly معمولاً کنترل مهمی در برابر سرقت مستقیم Cookie از JavaScript است.

Domain بیش از حد گسترده

Cookie نباید بدون نیاز برای تمام Subdomainها در دسترس باشد.

Logout فقط در Front-end

Backend باید Session را Revoked کند.

Session بدون Timeout

Session دائمی Window سوءاستفاده را افزایش می‌دهد.

حفظ Session بعد از تغییر Password

Policy Session باید رویدادهای امنیتی را در نظر بگیرد.

اعتماد کامل به Remember Me

Persistent Login Token نیز نیازمند Lifecycle، Rotation و Revocation است.

ساخت Session Engine اختصاصی

Authentication و Session Management حوزه‌های پرریسکی هستند.

استفاده از Framework معتبر معمولاً بهتر از اختراع الگوریتم اختصاصی است.

معماری پیشنهادی برای Session امن

یک طراحی مناسب را می‌توان چند لایه دید.

لایه اول: Transport

تمام مسیرهای Authenticated باید HTTPS باشند.

HTTP باید به HTTPS Redirect شود و Configuration مناسب HSTS در صورت امکان بررسی شود.

لایه دوم: Cookie

Session Cookie باید با Attributeهای مناسب تنظیم شود:

Secure

HttpOnly

SameSite متناسب با Application

Domain محدود

Path مناسب

لایه سوم: Session Generation

Session ID باید:

Server-generated،

Random،

غیرقابل پیش‌بینی،

و به اندازه کافی طولانی

باشد.

لایه چهارم: Lifecycle

Session باید در نقاط مهم Rotate شود:

Login

Privilege Change

Reauthentication

و رویدادهای حساس براساس Policy.

لایه پنجم: Revocation

Logout و Incident Response باید بتوانند Session را واقعاً Invalid کنند.

لایه ششم: Timeout

Idle و Absolute Timeout تعریف شوند.

لایه هفتم: Monitoring

رویدادهای Session و رفتارهای غیرعادی ثبت و تحلیل شوند.

مدل امن Login

یک Login Flow امن را می‌توان به‌صورت مفهومی چنین طراحی کرد:

1. Anonymous request
2. Anonymous session created
3. Credentials submitted securely
4. Credentials validated
5. MFA validated if required
6. Old session identifier retired
7. New cryptographically random session created
8. Authenticated state attached to new session
9. Secure cookie returned
10. Security event logged

این مدل مرز مشخصی بین Anonymous و Authenticated ایجاد می‌کند.

چرا Session Rotation فقط یک خط کد نیست؟

ممکن است توسعه‌دهنده تصور کند فراخوانی یک Function تمام مشکل را حل کرده است.

اما باید بررسی شود:

Session قبلی واقعاً Invalid شده؟

State لازم منتقل شده؟

Requestهای هم‌زمان چه می‌شوند؟

Cookie جدید Attribute درست دارد؟

Authentication State فقط روی Session جدید است؟

Load Balancer و Session Store هماهنگ هستند؟

Logout Session را حذف می‌کند؟

بنابراین Rotation باید در قالب Lifecycle کامل دیده شود.

Fail Secure در مدیریت Session

اگر Session Store در دسترس نباشد، Application باید رفتار مشخصی داشته باشد.

برای بخش‌های حساس معمولاً امن نیست که سیستم بگوید:

«Session را نمی‌توانم بررسی کنم، پس اجازه می‌دهم.»

این رفتار Fail Open است.

در Authentication معمولاً Failure Validation باید باعث Deny Access شود.

Availability مهم است، اما نباید به قیمت دورزدن احراز هویت تمام شود.

Session Fixation و Cache

صفحات Authenticated نباید به شکلی Cache شوند که داده Session یک User برای User دیگر نمایش داده شود.

این مشکل Session Fixation نیست، اما در طراحی Session Security باید Cache Layer نیز بررسی شود.

خصوصاً:

CDN

Reverse Proxy

Full-page Cache

و Edge Cache.

Responseهای خصوصی باید Header و Cache Policy صحیح داشته باشند.

Session Fixation و Load Balancer

در معماری چندسروری Session ممکن است:

Sticky Session باشد،

در Redis ذخیره شود،

در Database ذخیره شود،

یا Token-based باشد.

Session Rotation باید در تمام Nodeها به شکل سازگار اعمال شود.

نباید Server A Session قبلی را باطل کند ولی Server B همچنان آن را معتبر بداند.

Shared Session Store و Consistency اهمیت زیادی دارند.

Microserviceها و Session

در معماری Microservice بهتر است هر Service مستقیماً Session Cookie مرورگر را به‌عنوان اعتماد کامل دریافت نکند، مگر معماری به‌صورت آگاهانه چنین طراحی شده باشد.

Gateway یا Identity Layer می‌تواند Authentication را انجام دهد و Identity قابل اعتماد را به Serviceها منتقل کند.

اما Serviceهای حساس همچنان باید Authorization مناسب داشته باشند.

Session Security جای Object-level Authorization را نمی‌گیرد.

Session Fixation و Zero Trust

Zero Trust به معنای حذف Session نیست.

بلکه تصمیم‌های دسترسی باید براساس Context و Least Privilege انجام شوند.

حتی Session معتبر نباید مجوز نامحدود ایجاد کند.

Authentication و Authorization باید جدا باشند.

Session مشخص می‌کند User چه کسی است.

Authorization مشخص می‌کند User چه کاری می‌تواند انجام دهد.

آیا کوتاه کردن Session Timeout مشکل را حل می‌کند؟

خیر.

Timeout کوتاه Window حمله را کاهش می‌دهد اما Session Fixation را از بین نمی‌برد.

اگر همان ID پس از Login حفظ شود، حتی Session پنج‌دقیقه‌ای نیز در آن بازه آسیب‌پذیر است.

راهکار اصلی Rotation است.

آیا Captcha جلوی Session Fixation را می‌گیرد؟

خیر.

Captcha برای مقابله با Automation در برخی سناریوها کاربرد دارد.

Session Fixation یک ضعف Lifecycle در Session است.

Captcha Session ID را Regenerate نمی‌کند.

آیا WAF می‌تواند Session Fixation را متوقف کند؟

WAF می‌تواند فعالیت‌های غیرعادی، Botها یا برخی Patternها را شناسایی کند.

اما نمی‌تواند یک Application را مجبور کند پس از Login Session ID جدید تولید کند، مگر قابلیت بسیار خاص Application-aware داشته باشد.

رفع اصلی باید در Application یا Authentication Framework انجام شود.

امنیت API و Session

APIهایی که از Cookie-based Session استفاده می‌کنند نیز همان اصول را دارند.

اگر API Authentication از Session Cookie استفاده می‌کند:

Cookie Security،

CSRF Protection،

Rotation،

Timeout،

و Authorization

باید بررسی شوند.

API Token-based نیز Lifecycle مخصوص خودش را دارد.

Session Fixation در Mobile App

اپلیکیشن موبایل ممکن است Cookie Session یا Token داشته باشد.

اگر Authentication Token قبل و بعد از Login یا Privilege Change به شکل ناامن Reuse شود، مفاهیم مشابهی ایجاد می‌شوند.

Tokenها باید در Storage امن پلتفرم نگهداری شوند و Rotation و Revocation داشته باشند.

چک‌لیست جلوگیری از Session Fixation

پیش از انتشار سیستم Authentication موارد زیر بررسی شوند:

• Session ID پس از Login تغییر می‌کند.
• Session قبلی بعد از Login معتبر باقی نمی‌ماند.
• Session ID بعد از افزایش Privilege Rotate می‌شود.
• شناسه Session توسط Server تولید می‌شود.
• Client اجازه تعیین Arbitrary Session ID ندارد.
• Session ID از CSPRNG مناسب ساخته می‌شود.
• Identifier قابل پیش‌بینی نیست.
• Session ID در URL قرار نمی‌گیرد.
• Session Cookie دارای Secure است.
• Session Cookie دارای HttpOnly است.
• SameSite براساس معماری تنظیم شده است.
• Domain Cookie بیش از حد گسترده نیست.
• Path براساس نیاز تنظیم شده است.
• HTTPS برای کل Session فعال است.
• Credential Session در Log ثبت نمی‌شود.
• Error Page توکن را افشا نمی‌کند.
• Logout باعث Server-side Revocation می‌شود.
• Idle Timeout تعریف شده است.
• Absolute Timeout تعریف شده است.
• Password Change روی Session Policy اثر دارد.
• Password Reset Sessionهای قبلی را براساس Policy باطل می‌کند.
• MFA Transition به‌درستی مدیریت می‌شود.
• Remember Me Token مستقل و امن است.
• Active Sessions قابل مدیریت هستند.
• Session Store دسترسی محدود دارد.
• Session Rotation در معماری چندسروری سازگار است.
• Requestهای هم‌زمان هنگام Rotation بررسی شده‌اند.
• رفتار Invalid Session Log می‌شود.
• Session ID خام در Monitoring ذخیره نمی‌شود.
• Framework امنیتی معتبر استفاده شده است.
• Authentication و Authorization از هم جدا هستند.
• تغییر Role یا Tenant به‌صورت امن مدیریت می‌شود.
• تست Session Lifecycle در CI یا تست امنیت وجود دارد.

چگونه Session Management را در تست امنیت بررسی کنیم؟

تست Session فقط بررسی Cookie Attributeها نیست.

باید کل Lifecycle بررسی شود.

مرحله اول: ایجاد Session

آیا Application برای User ناشناس Session ایجاد می‌کند؟

شناسه چقدر Random به نظر می‌رسد؟

مرحله دوم: Login

آیا بعد از Login Identifier تغییر می‌کند؟

مرحله سوم: Session قدیمی

آیا Credential قبلی Invalid است؟

مرحله چهارم: Privilege Change

آیا Session پس از ارتقای دسترسی Rotate می‌شود؟

مرحله پنجم: Logout

آیا Session Server-side باطل می‌شود؟

مرحله ششم: Timeout

آیا Idle و Absolute Timeout واقعاً اعمال می‌شوند؟

مرحله هفتم: Cookie

آیا Secure، HttpOnly، SameSite، Domain و Path مطابق Policy هستند؟

مرحله هشتم: Concurrent Session

آیا چند Session مجاز هستند؟

اگر مجازند، User می‌تواند آن‌ها را مدیریت کند؟

مرحله نهم: Password Reset

آیا Sessionهای قبلی براساس Policy امنیتی Revoked می‌شوند؟

Session Management و E-Commerce

در فروشگاه‌های اینترنتی Anonymous Session اهمیت زیادی دارد، چون سبد خرید پیش از Login ساخته می‌شود.

در Login باید Cart State در صورت نیاز به Session جدید منتقل شود.

اما نباید فقط Anonymous Session به Authenticated تبدیل شود و Identifier ثابت بماند.

طراحی صحیح:

Anonymous Cart Session
↓
Login
↓
New Authenticated Session ID
↓
Safely migrate cart state

این مثال نشان می‌دهد Session Regeneration به معنی از دست دادن User Experience نیست.

Session Fixation در پنل ادمین

پنل‌های مدیریتی حساسیت بیشتری دارند.

اگر یک User عادی به Admin Mode وارد می‌شود، بهتر است Privilege Boundary واضح باشد.

موارد پیشنهادی:

Reauthentication

2FA

Session Rotation

Shorter Timeout

Audit Logging

Stronger Authorization

Admin Session نباید صرفاً همان User Session با یک Flag اضافی ناامن باشد.

Session Fixation در سیستم بانکی و مالی

در سامانه‌های مالی Session Security اهمیت بسیار بالاتری دارد.

علاوه بر کنترل‌های پایه ممکن است نیاز باشد:

Device Risk بررسی شود،

Reauthentication برای تراکنش مهم انجام شود،

Session Lifetime کوتاه‌تر باشد،

فعالیت غیرعادی Alert شود،

و Sensitive Action نیازمند Step-up Authentication باشد.

Session Fixation تنها یکی از Threatهای این محیط است.

Threat Modeling برای Session

برای هر سیستم می‌توان سؤالات زیر را مطرح کرد:

Session چه زمانی ساخته می‌شود؟

چه کسی Identifier را تولید می‌کند؟

Session در کجا ذخیره می‌شود؟

چه زمانی Rotate می‌شود؟

چه زمانی Invalid می‌شود؟

آیا Anonymous Session داریم؟

چه Stateهایی از Anonymous به Authenticated منتقل می‌شوند؟

چه Privilege Transitionهایی وجود دارند؟

Cookie روی چه Domainهایی معتبر است؟

آیا Subdomain ناامن در Scope Cookie وجود دارد؟

اگر Session Store لو برود چه می‌شود؟

اگر XSS رخ دهد چه چیزی قابل دسترسی است؟

Logout دقیقاً چه کاری می‌کند؟

Password Reset چه Sessionهایی را می‌بندد؟

این سؤالات معمولاً بسیاری از ضعف‌های Session Management را قبل از Production آشکار می‌کنند.

Secure by Design در مدیریت Session

بهترین رویکرد این است که Session Security از ابتدا در معماری Authentication طراحی شود.

نه اینکه در انتهای پروژه چند Attribute Cookie اضافه شود.

تیم باید Session State Machine مشخصی داشته باشد.

برای مثال:

ANONYMOUS
↓
PRIMARY_AUTH_OK
↓
MFA_REQUIRED
↓
AUTHENTICATED
↓
ELEVATED_PRIVILEGE
↓
LOGGED_OUT

هر Transition باید:

Permission مشخص،

Session Policy مشخص،

Rotation Policy،

و Logging مناسب

داشته باشد.

اصل Least Privilege در Session

Session فقط باید حداقل دسترسی لازم را داشته باشد.

اگر User یک Function خاص را نیاز ندارد، Authentication نباید به معنی دسترسی به آن Function باشد.

Roleها و Scopeها باید در Backend enforce شوند.

حتی اگر Session به سرقت برود، Least Privilege می‌تواند Impact را کاهش دهد.

Defense in Depth برای Session Fixation

هیچ کنترل واحدی نباید تنها خط دفاع باشد.

یک معماری مناسب می‌تواند شامل:

Session ID Regeneration

Strict Session Management

Secure Random Token

HTTPS

Secure Cookie

HttpOnly

SameSite

Short-lived Sessions

Reauthentication

2FA

Authorization

Monitoring

Revocation

باشد.

اگر یکی از لایه‌ها شکست بخورد، لایه‌های دیگر می‌توانند Impact را کاهش دهند.

سؤالات متداول درباره Session Fixation

Session Fixation چیست؟

Session Fixation یا تثبیت نشست آسیب‌پذیری‌ای است که در آن مهاجم Session ID مشخصی را قبل از Login قربانی می‌شناسد و تلاش می‌کند قربانی با همان Session احراز هویت شود. اگر برنامه پس از Login شناسه جدید ایجاد نکند، Session شناخته‌شده به نشست معتبر کاربر تبدیل می‌شود.

تفاوت Session Fixation با Session Hijacking چیست؟

در Session Fixation مهاجم معمولاً Session ID را قبل از Login قربانی می‌داند، اما در Session Hijacking تلاش می‌کند Session احراز هویت‌شده موجود را پس از Login سرقت کند. کنترل اصلی Fixation، Regenerate کردن Session ID پس از Authentication است.

آیا Session Fixation باعث هک حساب می‌شود؟

اگر آسیب‌پذیری قابل سوءاستفاده باشد و Session احراز هویت‌شده در اختیار فرد غیرمجاز قرار گیرد، ممکن است به تصاحب نشست و در نتیجه دسترسی به حساب منجر شود. میزان Impact به Permissionهای Session و کنترل‌های اضافی بستگی دارد.

بهترین راه جلوگیری از Session Fixation چیست؟

مهم‌ترین کنترل، تولید Session ID جدید پس از Login و Invalid کردن Identifier قبلی است. این کار باید پس از تغییرات مهم Privilege نیز انجام شود.

آیا HTTPS از Session Fixation جلوگیری می‌کند؟

HTTPS از انتقال Session در برابر شنود و دستکاری شبکه محافظت می‌کند، اما اگر Application پس از Login Session ID را تغییر ندهد، مشکل Session Fixation همچنان باقی است.

آیا HttpOnly جلوی Session Fixation را می‌گیرد؟

خیر. HttpOnly دسترسی JavaScript به Cookie را محدود می‌کند و بیشتر برای کاهش ریسک سرقت Cookie در برخی سناریوهای XSS مفید است. Session Regeneration همچنان لازم است.

آیا SameSite از Session Fixation جلوگیری می‌کند؟

خیر. SameSite بیشتر ارسال Cookie در Requestهای Cross-site را کنترل می‌کند و می‌تواند در دفاع در برابر برخی حملات مانند CSRF کمک کند. کنترل اصلی Session Fixation نیست.

آیا بعد از Login باید Session ID تغییر کند؟

بله. تغییر Session Identifier پس از Authentication یکی از مهم‌ترین اصول Session Management امن است.

آیا بعد از تغییر Role هم Session باید تغییر کند؟

در تغییرات مهم سطح دسترسی، Rotation Session ID توصیه می‌شود تا Session سطح پایین مستقیماً به Session سطح بالاتر تبدیل نشود.

آیا بعد از Logout فقط حذف Cookie کافی است؟

خیر. Session باید در سمت Server نیز Invalid یا Revoked شود. حذف Cookie فقط Browser فعلی را تحت تأثیر قرار می‌دهد.

Session Hijacking چیست؟

Session Hijacking به تصاحب Session معتبر کاربر گفته می‌شود. مهاجم معمولاً Session Token یا Identifier کاربر احراز هویت‌شده را به دست می‌آورد و از آن برای Impersonation استفاده می‌کند.

Session ID باید کجا ذخیره شود؟

در برنامه‌های وب سنتی، Cookie با تنظیمات امنیتی مناسب معمولاً گزینه رایجی است. انتخاب نهایی به Architecture و Threat Model بستگی دارد.

آیا Session ID را می‌توان در LocalStorage قرار داد؟

از نظر فنی امکان‌پذیر است، اما LocalStorage برای JavaScript قابل دسترسی است و در صورت XSS ریسک سرقت Token افزایش پیدا می‌کند. تصمیم باید براساس Threat Model باشد.

Session Timeout چقدر باشد؟

عدد ثابتی برای همه برنامه‌ها وجود ندارد. سیستم بانکی، فروشگاه و انجمن اینترنتی Riskهای متفاوتی دارند. Idle و Absolute Timeout باید براساس حساسیت اطلاعات و تجربه کاربری تعیین شوند.

آیا WordPress ممکن است Session Fixation داشته باشد؟

Core یا Pluginهای مختلف رفتارهای متفاوتی دارند. خطر بیشتر زمانی ایجاد می‌شود که Plugin یا کد سفارشی Login، SSO، Membership یا Session اختصاصی ایجاد کند و Lifecycle Token به‌درستی مدیریت نشود.

آیا WAF مشکل Session Fixation را برطرف می‌کند؟

خیر. WAF نمی‌تواند جای Session ID Rotation داخل Application را بگیرد. رفع اصلی باید در Authentication و Session Management انجام شود.

آیا 2FA از Session Fixation جلوگیری می‌کند؟

2FA امنیت Login را افزایش می‌دهد اما اگر Session بعد از تکمیل Authentication Rotate نشود، ضعف Session Management ممکن است همچنان وجود داشته باشد. بعد از تکمیل 2FA نیز Session Lifecycle باید صحیح باشد.

جمع‌بندی

Session Fixation یکی از مهم‌ترین ضعف‌های Session Management است که ریشه آن در نحوه مدیریت Session Identifier هنگام تغییر وضعیت امنیتی کاربر قرار دارد. در این آسیب‌پذیری مهاجم به‌جای سرقت Session تصادفی کاربر پس از Login، تلاش می‌کند قربانی را وارد Sessionی کند که Identifier آن از قبل شناخته شده است.

اگر وب‌سایت بعد از Login همان Session ID ناشناس را حفظ کند، Session شناخته‌شده ممکن است به Session احراز هویت‌شده تبدیل شود.

تفاوت اصلی Session Fixation با Session Hijacking نیز در همین نقطه است. در Session Hijacking مهاجم معمولاً یک Session فعال و معتبر را سرقت می‌کند، در حالی که در Session Fixation Session پیش از Authentication شناخته شده و بعداً اعتبار پیدا می‌کند.

مهم‌ترین راه جلوگیری از Session Fixation بسیار روشن است: پس از Authentication و تغییرات مهم Privilege، Session ID باید Regenerate شود و Identifier قبلی دیگر نباید برای دسترسی Authenticated معتبر باشد.

با این حال امنیت Session فقط به Rotation محدود نیست.

Session ID باید تصادفی و غیرقابل پیش‌بینی باشد، Server آن را تولید کند، در URL قرار نگیرد، از طریق HTTPS منتقل شود و داخل Cookie امن با Attributeهایی مانند Secure و HttpOnly نگهداری شود. SameSite، Scope محدود Domain و Path، Idle Timeout، Absolute Timeout، Logout واقعی و Monitoring نیز بخش‌های مهم معماری Session امن هستند.

تیم‌های توسعه باید همچنین تفاوت Authentication و Authorization را حفظ کنند. داشتن Session معتبر نباید به معنی دسترسی نامحدود به تمام Resourceها باشد.

در نهایت Secure Session Management یک Lifecycle کامل است:

Session باید به شکل امن ایجاد شود، هنگام تغییر سطح اعتماد Rotate شود، در مدت استفاده محافظت شود، فعالیت آن قابل Audit باشد و در پایان واقعاً Revoked شود.

اگر این چرخه به‌درستی طراحی شود، نه تنها ریسک Session Fixation بلکه بخش بزرگی از حملات مرتبط با تصاحب نشست نیز به شکل قابل‌توجهی کاهش پیدا می‌کند.