session hijacking چیست؟ سرقت کوکی و بدافزارهای سارق اطلاعات

سرویس ایمیل شما هشدار «ورود تازه» از کشوری می‌فرستد که هرگز به آن سفر نکرده‌اید. رمز عبورتان بلند و یکتاست و احراز هویت دوعاملی (⁦2FA⁩) هم روشن است؛ پس کسی چیزی را حدس نزده است. آنچه به احتمال زیاد از رایانه شما بیرون رفته، رمز عبور نبوده، بلکه کوکی کوچکی بوده که مرورگرتان پس از ورود دریافت کرده است. هر کسی که نسخه‌ای از آن کوکی را داشته باشد، تا جایی که وب‌سایت می‌تواند تشخیص دهد، خود شماست.

این نوشته توضیح می‌دهد کوکی نشست چیست، چگونه دزدیده می‌شود (نخست بدافزارهای سارق اطلاعات، چون بیشتر موارد از آنجا شروع می‌شوند)، چرا از احراز هویت دوعاملی می‌گذرد و چه باید کرد. بخش‌های جداگانه‌ای هم به این می‌پردازند که صاحبان سایت چه چیزهایی را باید تنظیم کنند و چرا سایت‌ها نشانی IP و دستگاه پشت یک نشست را زیر نظر دارند.

session hijacking چیست؟#

session hijacking یا ربودن نشست، که به آن cookie hijacking یا session theft هم می‌گویند، تصاحب یک نشست وب است که کاربری واقعی آن را آغاز کرده است. مهاجم از صفحه ورود وارد نمی‌شود. او مدرک ورودی را دوباره به کار می‌برد که سایت پس از ورود به کاربر داده است.

OWASP Session Management Cheat Sheet توضیح می‌دهد چرا این موضوع مهم است: وقتی نشستی ساخته شد، شناسه آن «به‌طور موقت هم‌ارز قوی‌ترین روش احراز هویتی است که برنامه به کار می‌برد». اگر با رمز عبور و یک کلید امنیتی وارد شده باشید، کوکی تا وقتی معتبر است به اندازه هر دوی آن‌ها ارزش دارد.

کوکی نشست چیست و چرا ارزش دزدیدن دارد؟#

وب‌سایت‌ها در هر کلیک رمز عبور شما را نمی‌پرسند. پس از ورود، سرور یک مقدار تصادفی بلند به نام شناسه نشست (session ID) می‌سازد و آن را در یک کوکی به مرورگر شما می‌فرستد؛ مرورگر هم آن را با هر درخواست برمی‌گرداند. این کار مثل کارت‌کلید هتل است: پذیرش یک بار کارت شناسایی شما را بررسی می‌کند و از آن پس کارت تا وقتی منقضی نشده، در اتاق را باز می‌کند.

اپلیکیشن‌ها همین کار را با توکن دسترسی و توکن تازه‌سازی (access token و refresh token) انجام می‌دهند. مرجع Set-Cookie در MDN عبارت «کوکی نشست» را به معنای دقیق فقط برای کوکی بدون تاریخ انقضا به کار می‌برد که با بسته شدن مرورگر پاک می‌شود. کوکی‌های ورود اغلب عمر بیشتری دارند: گزینه «وارد بمانم» آن‌ها را هفته‌ها معتبر نگه می‌دارد و همین است که نسخه دزدیده‌شده را به کار مهاجم می‌آورد.

session hijacking چگونه کار می‌کند؟#

1. وارد حساب می‌شوید، با رمز عبور و یک کد یا تأیید روی گوشی. این تنها لحظه‌ای است که احراز هویت دوعاملی بررسی می‌شود.
2. سایت یک کوکی نشست صادر می‌کند. از این پس فقط همین کوکی شما را وارد نگه می‌دارد.
3. نسخه‌ای از دست شما خارج می‌شود. بدافزار انبار کوکی مرورگر را می‌خواند، یک صفحه ورود جعلی ورود شما را به سایت واقعی می‌رساند و کوکی را برای خود نگه می‌دارد، یا باگی در سایت آن را لو می‌دهد.
4. نسخه در جای دیگری به کار می‌رود. سرور یک نشست معتبر می‌بیند و چیزی نمی‌پرسد. MITRE ATT&CK، فهرست عمومی تکنیک‌های مهاجمان، می‌گوید این کار «برخی پروتکل‌های احراز هویت چندعاملی را دور می‌زند، چون نشست از پیش احراز هویت شده است» (⁦T1550.004⁩). تیم‌های امنیتی به آن «pass the cookie» می‌گویند.
5. مهاجم جای پای خود را محکم می‌کند: ایمیل بازیابی تازه، قاعده ارسال خودکار نامه، خرید، پیش از آنکه نشست منقضی شود.

دفاع در مرحله 3 (جلوگیری از خروج نسخه)، مرحله 4 (بی‌مصرف کردن نسخه در جای دیگر) و مرحله 5 (دیدن سریع آن) قرار می‌گیرد.

مهاجمان کوکی نشست را چگونه می‌دزدند؟#

فیشینگی که ورود را واسطه‌گری می‌کند. برخی صفحه‌های فیشینگ میان شما و سایت واقعی می‌نشینند، رمز و کد شما را به آن می‌رسانند و کوکی نشستی را که سایت واقعی برمی‌گرداند نگه می‌دارند؛ MITRE این مسیر «پروکسی مخرب» را زیر سرقت کوکی‌های نشست وب آورده است. passkeyها جلوی آن را می‌گیرند: FIDO Alliance آن‌ها را اطلاعات ورودی مقاوم در برابر فیشینگ توصیف می‌کند که به حساب شما در یک وب‌سایت مشخص گره خورده‌اند.

اسکریپت‌نویسی میان‌سایتی. اسکریپتی که از راه یک باگ به صفحه‌های سایت راه پیدا کرده، طوری اجرا می‌شود که انگار خود سایت آن را نوشته است و می‌تواند هر کوکی بدون پرچم HttpOnly را بخواند.

شنود نشست. در شبکه‌ای که در اختیار شما نیست، ترافیک رمزگذاری‌نشده خواندنی است؛ HTTPS این راه را برای کوکی می‌بندد و نوشته آیا وای‌فای عمومی امن است؟ توضیح می‌دهد چه چیزهایی همچنان دیده می‌شوند. خواندن ترافیک HTTPS تنها وقتی ممکن است که دستگاه شما به یک گواهی ریشه اضافی اعتماد کند. توسعه‌دهندگان عمداً چنین گواهی‌ای اضافه می‌کنند تا روی رایانه خودشان با یک پروکسی MITM اشکال‌زدایی کنند؛ هرگز فقط به این دلیل که یک شبکه یا وب‌سایت از شما می‌خواهد، چنین گواهی‌ای نصب نکنید.

بدافزار سارق اطلاعات چیست و چگونه از احراز هویت دوعاملی می‌گذرد؟#

بدافزار سارق اطلاعات (infostealer) نرم‌افزار مخربی است که داده‌های ذخیره‌شده را از رایانه کپی می‌کند و در عرض چند دقیقه به بیرون می‌فرستد: رمزهای ذخیره‌شده در مرورگر، کوکی‌ها، داده‌های تکمیل خودکار، کیف‌پول‌های رمزارز و توکن‌های اپلیکیشن‌ها. این غنیمت، که به آن «stealer log» می‌گویند، به‌صورت عمده فروخته می‌شود.

هشدار مشترک FBI و CISA درباره بدافزار ⁦LummaC2⁩ به تاریخ 21 مه 2025 فهرست می‌کند که چنین بدافزاری چه چیزهایی را می‌برد، از «اطلاعات ورود مالی» تا «جزئیات احراز هویت چندعاملی (MFA)»، و از چه راهی می‌رسد: ایمیل‌های فیشینگ، نرم‌افزارهای جعلی یا کرک‌شده و صفحه‌های CAPTCHA جعلی. این صفحه‌ها از بازدیدکننده می‌خواهند Windows + R را بزند، با Ctrl + V چیزی را بچسباند و Enter را بزند؛ با این کار فرمان مهاجم اجرا می‌شود. هیچ بررسی واقعی «آیا انسان هستید» چنین چیزی نمی‌خواهد.

احراز هویت دوعاملی وقتی کوکی رفته باشد کمکی نمی‌کند، چون خود کوکی نتیجه ورودی است که از پیش از احراز هویت دوعاملی گذشته است. در پایان اوت 2026، Anthropic کاربرانی از Claude را که نشست‌هایشان به دست بدافزارهای سارق اطلاعات روی رایانه‌های خودشان کپی شده بود از حساب خارج کرد و هشدار داد که خروج از حساب «بدافزار را پاک نمی‌کند» (Help Net Security). تا وقتی دستگاه آلوده بماند، نشست بعدی هم کپی می‌شود.

Have I Been Pwned هم stealer logها را بارگذاری می‌کند: نشانی ایمیل خود را از راه سرویس رایگان اطلاع‌رسانی آن تأیید کنید تا وب‌سایت‌هایی را ببینید که نشانی شما در کنار آن‌ها آمده است، و هر کدام از آن‌ها را لورفته در نظر بگیرید.

مقایسه session hijacking با credential stuffing، فیشینگ و CSRF#

در CSRF کوکی هرگز مرورگر شما را ترک نمی‌کند؛ session hijacking آن را به دستگاه دیگری می‌برد.

نشانه‌های ربوده شدن نشست شما#

• هشدار «ورود تازه» که خودتان باعثش نبوده‌اید، یا دستگاهی ناشناس در فهرست نشست‌های فعال حساب.
• تغییراتی که خودتان انجام نداده‌اید: ایمیل یا تلفن بازیابی، قاعده‌های ارسال خودکار نامه، برنامه‌های متصل، روش‌های پرداخت.
• پیام‌ها یا سفارش‌هایی که نفرستاده‌اید، یا موجودی یا سهمیه مصرفی که در نبود شما کم می‌شود.
• خارج شدن ناگهانی از حساب، گاهی به این دلیل که سایت نسخه دومی از نشست شما را دیده است.

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

اگر نشست شما دزدیده شد چه کنید#

1. نخست دستگاه را پاک کنید. با نرم‌افزار امنیتی خود یک اسکن کامل اجرا کنید؛ اگر بدافزار سارق اطلاعات پیدا کرد یا مطمئن نیستید، از فایل‌هایتان نسخه پشتیبان بگیرید و سیستم‌عامل را دوباره نصب کنید. در غیر این صورت بدافزار به‌سادگی نشست بعدی شما را هم کپی می‌کند.
2. از یک دستگاه پاک همه نشست‌ها را ببندید. در حساب گوگل: حساب Google > امنیت و ورود به سیستم > دستگاه‌های شما > مدیریت همه دستگاه‌ها؛ سپس هر دستگاه ناشناس را انتخاب کنید و روی خروج از سیستم بزنید (مراحل گوگل). بیشتر سرویس‌های بزرگ فهرست مشابهی دارند.
3. رمز عبور را عوض کنید. گوگل پس از آن شما را در همه‌جا از حساب خارج می‌کند، جز چند دستگاه که در صفحه راهنمای گذرواژه آن آمده‌اند؛ سرویس‌های دیگر ممکن است نشست‌های قدیمی را زنده نگه دارند، پس مرحله 2 را هم انجام دهید.
4. بررسی کنید چه چیزی جا مانده است: اطلاعات بازیابی، ارسال خودکار نامه، برنامه‌های متصل، روش‌های پرداخت. سپس هر جا که ممکن است یک passkey اضافه کنید.

چگونه به‌عنوان کاربر جلوی session hijacking را بگیرید#

• نرم‌افزار را فقط از منبع رسمی نصب کنید و هرگز فرمانی را که یک صفحه وب از شما می‌خواهد اجرا کنید، نچسبانید.
• از passkey یا کلید امنیتی استفاده کنید. صفحه فیشینگ می‌تواند یک کد را واسطه‌گری کند، اما passkey را نه.
• در رایانه‌های مشترک گزینه «وارد بمانم» را انتخاب نکنید و هنگام رفتن از حساب خارج شوید.
• گاه‌به‌گاه نشست‌های فعال حساب ایمیل خود را مرور کنید.
• افزونه‌های مرورگر را که دیگر استفاده نمی‌کنید حذف کنید؛ افزونه‌ای با مجوزهای گسترده می‌تواند کوکی‌ها را بخواند.
• مرورگر را به‌روز نگه دارید، چون محافظت‌هایی مانند نشست‌های وابسته به دستگاه از راه به‌روزرسانی‌ها می‌رسند.

چگونه جلوی session hijacking را در سایت خود بگیرید#

cheat sheet سازمان OWASP مرجع این کار است. نکته‌هایی که بیشترین اهمیت را دارند:

1. پرچم‌های کوکی را تنظیم کنید. Secure (فقط HTTPS)، HttpOnly (بدون دسترسی اسکریپت)، SameSite=Lax یا Strict، و پیشوند __Host- که Secure و Path=/ را الزامی می‌کند و Domain را نمی‌پذیرد.
2. شناسه‌ها را حدس‌ناپذیر کنید: دست‌کم 64 بیت آنتروپی، از مولد خود فریم‌ورک، و هرگز در URL.
3. هنگام ورود و در هر تغییر سطح دسترسی، شناسه نشست تازه صادر کنید؛ این کار راه تثبیت نشست را می‌بندد.
4. نشست‌ها را منقضی کنید. نمونه‌های OWASP: مهلت بی‌فعالیتی 2 تا 5 دقیقه برای برنامه‌های پرارزش، 15 تا 30 دقیقه برای برنامه‌های کم‌خطر، و مهلت مطلق 4 تا 8 ساعت.
5. خروج از حساب را واقعی کنید. نشست را روی سرور باطل کنید و بگذارید کاربران نشست‌هایشان را ببینند و ببندند.
6. پیش از تغییرهای حساس دوباره احراز هویت بخواهید، مانند رمز عبور تازه، نشانی ایمیل تازه یا حساب دریافت وجه.
7. همه صفحه‌ها را با HTTPS و HSTS ارائه کنید تا مرورگرها هرگز به HTTP ساده برنگردند.

Set-Cookie: __Host-sid=<random value>; Path=/; Secure; HttpOnly; SameSite=Lax

Device Bound Session Credentials (DBSC)#

DBSC نشست را به دستگاهی که آن را ساخته است گره می‌زند. مرورگر یک کلید خصوصی را در سخت‌افزار امن نگه می‌دارد، مانند تراشه TPM در ویندوز، و هر بار که کوکی‌های کوتاه‌عمر سایت را تمدید می‌کند باید ثابت کند آن کلید را در اختیار دارد؛ پس کوکی کپی‌شده به‌زودی منقضی می‌شود و در جای دیگری تمدیدشدنی نیست. گوگل در 9 آوریل 2026 اعلام کرد که DBSC در کروم 146 روی ویندوز وارد مرحله دسترسی عمومی می‌شود، macOS پس از آن، و به‌عنوان یک استاندارد باز ⁦W3C⁩ عرضه می‌شود. مستندات کروم راه‌اندازی سمت سایت را شرح می‌دهد و هشدار می‌دهد بدافزاری که هنگام ثبت کلید از پیش روی دستگاه بوده، ممکن است بتواند کلید را بیرون بکشد.

چرا سایت‌ها نشست شما را به نشانی IP و دستگاه‌تان گره می‌زنند#

کمتر سایتی یک نشست را به یک نشانی IP قفل می‌کند، چون کاربران واقعی در طول روز میان وای‌فای و اینترنت همراه جابه‌جا می‌شوند. در عوض به نشستی توجه می‌کنند که ناگهان رفتارش عوض می‌شود: کوکی‌ای که برای یک لپ‌تاپ روی اتصال خانگی صادر شده، چند دقیقه بعد از یک شبکه میزبانی در کشوری دیگر و با اثر انگشت مرورگر متفاوتی پیدا می‌شود. این شبیه سرقت است، پس سایت نشست را می‌بندد یا از شما می‌خواهد دوباره وارد شوید. OWASP یادآوری می‌کند که مهاجم ماهر می‌تواند از پیوند نشست به IP و User-Agent بگذرد؛ پس این بررسی‌ها یک لایه‌اند، نه راه‌حل.

همین منطق کاربران درستکار را هم گیر می‌اندازد. اگر VPN یا پروکسی شما در میانه نشست کشور را عوض کند، یا یک پروکسی چرخشی به هر درخواست نشانی تازه‌ای بدهد، سایت یک نشست را می‌بیند که روی نقشه این‌سو و آن‌سو می‌پرد و شما را از حساب خارج می‌کند؛ نوشته چرا بانک ورود از یک مکان غیرعادی را مشکوک می‌داند؟ این را از نگاه کاربر نشان می‌دهد.

تیم‌هایی که از راه پروکسی وارد حساب‌ها می‌شوند و در آن‌ها کار می‌کنند، مانند آژانس‌هایی که حساب‌های تبلیغاتی مشتریان را اداره می‌کنند، برای هر حساب یک خروجی ثابت نگه می‌دارند. پروکسی با نشست ثابت یک IP را 1 تا 60 دقیقه بی‌تغییر نگه می‌دارد و پروکسی ISP نشانی‌ای را که به نام یک ارائه‌دهنده اینترنت ثبت شده، تا وقتی آن را اجاره کرده‌اید برای شما نگه می‌دارد؛ نوشته پلتفرم پرداخت و ثبات IP حالت مالی را بررسی می‌کند. پروکسی از کوکی در برابر سرقت محافظت نمی‌کند و شرایط خدمات Proxynet تلاش برای دسترسی غیرمجاز را ممنوع می‌کند.

session hijacking کجا بیشترین آسیب را می‌زند#

• بانک‌ها و اپلیکیشن‌های پرداخت، که در آن‌ها یک نشست ربوده‌شده می‌تواند پول جابه‌جا کند؛ صفحه مالی را ببینید.
• فروشگاه‌های اینترنتی و حساب‌های فروشنده، با کارت‌های ذخیره‌شده و اطلاعات دریافت وجه؛ صفحه تجارت الکترونیک را ببینید.
• شبکه‌های اجتماعی و حساب‌های تبلیغاتی، که در آن‌ها صفحه تصاحب‌شده می‌تواند کلاهبرداری منتشر کند یا بودجه را خرج کند؛ صفحه شبکه‌های اجتماعی نگه داشتن یک IP برای هر حساب را توضیح می‌دهد.
• پنل‌های مدیریت و ابزارهای شرکتی، که در آن‌ها یک نشست دزدیده‌شده می‌تواند داده مشتریان را افشا کند؛ صفحه امنیت داده آزمودن صفحه‌های ورود خودتان از بیرون را پوشش می‌دهد.

خطاهای رایج#

• اعتماد به احراز هویت دوعاملی برای محافظت از نشستی که از پیش باز است.
• خروج از حساب روی رایانه‌ای که هنوز آلوده است.
• عوض کردن رمز و فرض اینکه نشست‌های قدیمی بسته شده‌اند.
• سایت: خروجی که فقط کوکی را در مرورگر پاک می‌کند.
• سایت: قفل کردن سخت نشست به یک نشانی IP، که کاربران موبایل را از حساب بیرون می‌اندازد و مهاجم را به‌زحمت کُند می‌کند.

راهنمای انتخاب#

پرسش‌های متداول#

آیا session hijacking می‌تواند از احراز هویت دوعاملی بگذرد؟#

بله. احراز هویت دوعاملی هنگام ورود بررسی می‌شود و کوکی دزدیده‌شده نماینده ورودی است که از پیش از آن گذشته است. passkeyها جلوی مسیر فیشینگ را می‌گیرند، اما جلوی بدافزار روی دستگاه خودتان را نه.

آیا خروج از حساب مرا در برابر session hijacking محافظت می‌کند؟#

در سایتی که درست ساخته شده باشد، خروج از حساب نشست را روی سرور می‌بندد و کوکی کپی‌شده دیگر کار نمی‌کند. اما روی دستگاه آلوده، نشست بعدی دوباره کپی می‌شود؛ پس نخست دستگاه را پاک کنید.

آیا HTTPS جلوی session hijacking را می‌گیرد؟#

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

آیا VPN یا پروکسی می‌تواند جلوی session hijacking را بگیرد؟#

نه. هر دو مسیر شبکه را تغییر می‌دهند، اما بدافزار سارق اطلاعات کوکی را از دیسک شما می‌خواند و صفحه فیشینگ آن را مستقیم از خود شما می‌گیرد. VPN یا پروکسی رایگانی که یک غریبه اداره می‌کند حتی می‌تواند خطر را بیشتر کند؛ نوشته آیا پروکسی‌های رایگان امن هستند؟ را ببینید.

تفاوت session hijacking و session fixation چیست؟#

در hijacking، مهاجم شناسه نشستی را می‌گیرد که از قبل وجود دارد. در fixation (تثبیت نشست)، مهاجم پیش از ورود شما یک شناسه شناخته‌شده را جا می‌گذارد و منتظر می‌ماند تا شما با ورودتان آن را معتبر کنید؛ صادر کردن شناسه تازه هنگام ورود جلوی آن را می‌گیرد.

آیا session hijacking غیرقانونی است؟#

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

خلاصه#

session hijacking مرحله ورود را دور می‌زند: هر کسی که نسخه‌ای از کوکی یا توکن نشست شما را داشته باشد، به نام شما وارد است، چون رمز عبور و کد دوعاملی پیش‌تر بررسی شده‌اند. بیشتر موارد با بدافزار سارق اطلاعات روی رایانه خود قربانی شروع می‌شوند و پس از آن صفحه‌های فیشینگی که ورود را واسطه‌گری می‌کنند، باگ‌های XSS و اتصال‌های رمزگذاری‌نشده قرار دارند. کاربران با دستگاه پاک، passkey و نگاهی به نشست‌های فعالشان از خود دفاع می‌کنند؛ سایت‌ها با پرچم‌های سخت‌گیرانه کوکی، شناسه تازه در هر ورود، عمر کوتاه نشست، خروج واقعی و نشست‌های وابسته به دستگاه. اگر تیم شما از راه پروکسی در حساب‌ها کار می‌کند، با خدمات پروکسی ما هر حساب را روی یک نشانی پایدار نگه دارید.