Session Security: Cookies, Rotation, Logout, Hijack

یک login درست هنوز می‌تواند lifecycle ضعیفی برای session بسازد. اگر cookie بیش از حد لازم scope داشته باشد، شناسه‌ی pre-authentication بعد از login دوباره استفاده شود، server-side state هنگام logout باطل نشود یا reauthentication برای رخدادهای حساس وجود نداشته باشد، authority می‌تواند بیشتر از چیزی که طراحی شده زنده بماند. این درس فقط یک fixture محلی و کاملاً synthetic را بررسی می‌کند و هیچ session واقعی یا target بیرونی در آن وجود ندارد.

1. مسئله قبل از Cookie

سناریو یک web app مصنوعی با browsing ناشناس، sign-in، صفحه‌ی تنظیمات حساس و logout است. سؤال اصلی این نیست که «cookie داریم یا نه». سؤال این است که در هر lifecycle event کدام session handle معتبر است، authority کجا نگهداری می‌شود، چه زمانی rotation لازم است و چه evidenceای invalidation را ثابت می‌کند.

2. خروجی محدود درس

خروجی شما Session Lifecycle Security Record v1 است. هر ردیف باید Lifecycle Event، Session Handle State، Cookie Attributes، Server-side State، Rotation Required، Invalidation Expected، Probe، Observation، Decision و Residual Risk را ثبت کند.

3. این درس چه چیزی را ثابت نمی‌کند

این fixture اثبات production security نیست. HTTPS به‌تنهایی cookie configuration را امن نمی‌کند. SameSite جای همه‌ی دفاع‌های CSRF را نمی‌گیرد. حذف cookie در browser لزوماً authority سمت سرور را باطل نمی‌کند. طول زیاد و randomness شناسه نیز به‌تنهایی rotation، logout و reauthentication policy را حل نمی‌کند.

4. Session identifier به‌عنوان opaque reference

در مدل این درس session identifier فقط یک handle مصنوعی و فاقد معنای business است. user id، role یا اطلاعات حساس داخل خود identifier قرار نمی‌گیرد. state معنادار روی server-side session store نگهداری می‌شود. بنابراین مشاهده‌ی یک handle به‌تنهایی نباید به inference درباره‌ی privilege تبدیل شود.

5. مرز browser و server

Browser cookie یک حامل برای session handle است؛ authority اصلی در fixture روی SERVER_SESSION_STORE قرار دارد. این تفکیک برای logout مهم است: پاک کردن cookie می‌تواند handle را از browser بردارد، ولی تا زمانی که state سمت سرور invalidate نشده باشد، حذف client-side به‌تنهایی evidence کافی برای پایان authority نیست.

6. Cookie attributes به‌عنوان constraints

در baseline از cookie با Secure، HttpOnly، SameSite=Strict، Path=/ و بدون Domain استفاده می‌شود. این انتخاب‌ها scope و شیوه‌ی ارسال/دسترسی browser را محدود می‌کنند، ولی هیچ‌کدام جای server-side validation را نمی‌گیرند.

7. Secure

Secure یعنی browser cookie را فقط روی transport امن ارسال کند. این control مهم است اما proof کامل session security نیست. اگر rotation یا invalidation اشتباه باشد، وجود Secure آن خطاهای lifecycle را اصلاح نمی‌کند.

8. HttpOnly

HttpOnly دسترسی مستقیم scriptهای browser به cookie را محدود می‌کند. در این درس آن را یک defensive attribute می‌دانیم، نه یک guarantee عمومی در برابر همه‌ی compromiseها. Evidence نهایی باید همچنان lifecycle و server-side state را بررسی کند.

9. SameSite

SameSite روی ارسال cookie در contextهای cross-site اثر می‌گذارد. baseline این fixture Strict است تا scope تمرین روشن بماند. نتیجه‌ی درس این نیست که SameSite به‌تنهایی همه‌ی CSRF risk را حذف می‌کند؛ این موضوع عمداً خارج از outcome اصلی نگه داشته می‌شود.

10. Domain و Path

Domain و Path روی گستره‌ی ارسال cookie اثر دارند. baseline از __Host- style constraint استفاده می‌کند: بدون Domain و با Path=/. mutation آزمایشگاه scope را عمداً broad می‌کند تا learner مجبور شود expansion را تشخیص دهد و درباره‌ی ضرورت آن تصمیم بگیرد.

11. Anonymous session

چرخه از یک anonymous session مصنوعی شروع می‌شود. این handle فقط state ناشناس را نمایندگی می‌کند. login نباید همان handle را با authority جدید دوباره مصرف کند، زیرا مرز authentication یک تغییر مهم در privilege context است.

12. Authentication boundary

پس از sign-in، fixture باید یک identifier جدید تولید کند و handle قبلی را stale کند. Evidence لازم دو بخش دارد: session جدید معتبر است و replay شناسه‌ی pre-authentication رد می‌شود. فقط مشاهده‌ی session جدید بدون رد شدن session قدیمی کافی نیست.

13. Rotation

Rotation یعنی authority جدید به handle تازه متصل شود و handle قبلی authority جدید را حمل نکند. آزمایش rotation_disabled_at_authentication این invariant را می‌شکند و باید با SESSION_ROTATION_MISSING تشخیص داده شود.

14. Privilege change

Bible این درس rotation را در authentication و privilege-context change به‌عنوان boundary قابل بررسی نگه می‌دارد. fixture policy هر دو را صریح ثبت می‌کند. هدف، آموزش یک framework خاص نیست؛ هدف ساختن evidence برای lifecycle rule است.

15. Server-side invalidation

وقتی session پایان می‌یابد، رکورد server-side مربوط به آن باید دیگر authority معتبر ارائه نکند. در fixture، logout state را به invalid تبدیل می‌کند و probe بعدی روی همان handle باید رد شود.

16. Logout کامل

Logout در این درس دو observation جدا دارد: browser دیگر cookie قابل استفاده ندارد و server-side handle نیز invalid است. اگر فقط مورد اول رخ دهد، record باید نتیجه را incomplete اعلام کند و learner حق ندارد termination کامل را claim کند.

17. Replay یک شناسه‌ی stale

برای safe negative evidence فقط handleهای مصنوعی fixture replay می‌شوند. replay شناسه‌ی قدیمی پس از rotation یا logout باید در server boundary با STALE_SESSION_REJECTED رد شود. این تمرین هیچ credential، user واقعی یا session بیرونی را لمس نمی‌کند.

18. Hijack resistance با claim محدود

Rotation، scope مناسب، transport control، lifetime و reauthentication exposure به replay/hijack را کاهش می‌دهند، اما lesson ادعا نمی‌کند compromise غیرممکن می‌شود. Decision نهایی باید residual risk را صریح نگه دارد.

19. Reauthentication boundary

سناریوی transfer یک admin console مصنوعی است که پیش از تغییر recovery settings به reauthentication نیاز دارد. learner باید این risk event را به lifecycle record اضافه کند، بدون اینکه وارد طراحی WebAuthn یا recovery mechanism شود.

20. Fact، Observation و Inference

Secure=true یک fact پیکربندی است. old session rejected یک observation در fixture است. این نتیجه که «production در برابر همه‌ی session hijackها امن است» inference نامعتبر است. Record باید این سه سطح را از هم جدا نگه دارد.

21. Positive Evidence

positive path نشان می‌دهد anonymous session ساخته می‌شود، authentication identifier را rotate می‌کند، authenticated handle معتبر می‌شود و پس از reauthentication boundary عمل حساس فقط در context درست ادامه می‌یابد. positive evidence لازم است ولی کافی نیست.

22. Negative Evidence

Negative Evidence باید حداقل نشان دهد pre-authentication handle پس از rotation رد می‌شود، session پس از logout در server رد می‌شود، حذف صرف cookie proof invalidation نیست و broad شدن cookie scope توسط audit شناسایی می‌شود.

23. Mutation: rotation خاموش

در این mutation، rotate_on_authentication=false می‌شود. انتظار این نیست که login fail شود؛ اتفاقاً ممکن است login ظاهراً موفق باشد. failure مورد نظر این است که session handle تغییر نمی‌کند و evidence gate آن را تشخیص می‌دهد.

24. Mutation: فقط حذف cookie

در این case، client-side cookie حذف می‌شود ولی server-side state عمداً active می‌ماند. classification باید CLIENT_COOKIE_REMOVAL_NOT_SERVER_INVALIDATION باشد. این case misconception رایج «cookie پاک شد، پس session تمام شد» را جدا می‌کند.

25. Mutation: scope گسترده‌تر

fixture مقدار Domain یا constraintهای scope را broad می‌کند. این mutation به‌خودی‌خود exploit نیست؛ یک configuration review دفاعی است. learner باید expansion را مشاهده کند و ضرورت یا رد آن را با outcome محدود توجیه کند.

26. Evidence completeness

اگر یکی از fieldهای اصلی record حذف شود، validator باید artifact را incomplete اعلام کند. نتیجه‌ی امنیتی بدون evidence traceable قابل قبول نیست، حتی اگر همه‌ی testها سبز باشند.

27. اجرای Lab

از مسیر lab://SEC-003/SEC003-LAB1 runner محلی را اجرا کنید. ابتدا baseline را ثبت کنید، سپس probeهای safe را یکی‌یکی اجرا کنید. خروجی خام را نگه دارید و final Decision را قبل از مشاهده‌ی evidence پر نکنید.

28. ساخت Session Lifecycle Security Record v1

برای هر event یک row مستقل بسازید. Observation باید چیزی باشد که fixture واقعاً نشان داده است. Decision باید bounded باشد و Residual Risk چیزی را که هنوز ثابت نشده آشکار نگه دارد.

29. Transfer Case

Transfer Case: یک admin console مصنوعی قبل از تغییر recovery settings به reauthentication نیاز دارد. lifecycle record را با event جدید گسترش دهید، مشخص کنید session قبلی چه stateای دارد و evidence لازم برای ادامه‌ی عمل حساس چیست؛ وارد طراحی WebAuthn نشوید.

30. ارزیابی نهایی

پایان موفق یعنی learner بتواند lifecycle را مدل کند، cookie constraints را توضیح دهد، rotation و logout invalidation را با positive و negative evidence ثابت کند، observation را از inference جدا کند و changed-context decision را مستقل بنویسد.

31. منبع و freshness

مرجع رسمی این درس OWASP-SESSION است. snapshot frozen در 2026-09-02 گرفته شده و review_due آن 2026-10-02 است. Query 1 در 2026-09-16 داخل همین review window اجرا شده، بنابراین source scope گسترش داده نشده است.

32. مرز مسئولیت انسانی

AI می‌تواند بعد از بیان objective به پیشنهاد probe دفاعی یا مرتب‌سازی observationها کمک کند، اما حق ندارد evidence ندیده را بسازد، یک test سبز را proof security بنامد یا تصمیم نهایی risk/policy/owner را به‌جای learner بگیرد.