بررسی Testing Session Timeout
در این بخش از دوره آموزشی OWASP-WSTG به ششمین بخش از استاندارد WSTG با شناسه WSTG-SESS-07 می پردازیم که مربوط به بررسی Session Timeout می باشد.
خلاصه
در این مرحله، تست کنندگان بررسی می‌کنند که برنامه به طور خودکار یک کاربر را هنگامی که آن کاربر برای مدت زمان مشخصی بی‌کار بوده‌است، بیرون می‌کند و اطمینان می‌دهند که امکان “استفاده مجدد” از همان جلسه وجود ندارد و هیچ داده حساسی در Cache مرورگر ذخیره نمی‌شود.
تمام برنامه‌ها باید یک زمان بیکاری یا عدم فعالیت را برای جلسات اجرا کنند. این بخش، مقدار زمانی را تعریف می‌کند که یک جلسه فعال باقی می‌ماند. در صورتی که هیچ فعالیتی توسط کاربر وجود نداشته باشد، جلسه براساس دوره بیکاری تعریف‌شده از زمان آخرین درخواست HTTP دریافت‌شده توسط برنامه وب برای یک ID جلسه داده‌شده، بسته و ابطال می شود. مناسب‌ترین زمان اتمام باید تعادل بین امنیت (زمان اتمام کوتاه‌تر) و قابلیت استفاده (زمان اتمام طولانی‌تر) باشد و به شدت به سطح حساسیت داده‌های مدیریت‌شده توسط برنامه بستگی دارد.
به عنوان مثال، یک زمان اتمام ۶۰ دقیقه‌ای برای یک فروم عمومی می‌تواند قابل‌قبول باشد، اما چنین زمان طولانی در یک برنامه بانکداری بسیار زیاد خواهد بود (که در آن حداکثر زمان اتمام ۱۵ دقیقه‌ای توصیه می‌شود). در هر صورت، هر برنامه‌ای که یک log out مبتنی بر زمان را اجرا نمی‌کند باید ایمن در نظر گرفته نشود، مگر اینکه چنین رفتاری توسط یک الزام عملکردی خاص مورد نیاز باشد.
زمان بیکاری، فرصت‌هایی را که یک مهاجم باید یک ID جلسه معتبر را از کاربر دیگری حدس بزند و استفاده کند، محدود می‌کند و تحت شرایط خاصی می‌تواند از کامپیوترهای عمومی در برابر استفاده مجدد از نشست محافظت کند. با این حال، اگر مهاجم قادر به ربودن یک جلسه مشخص باشد، زمان بیکاری اقدامات مهاجم را محدود نمی‌کند، زیرا او می‌تواند فعالیت را به صورت دوره‌ای برای فعال نگه داشتن جلسه برای دوره‌های طولانی‌تر ایجاد کند.
مدیریت زمان اتمام نشست و انقضا باید در سمت سرور اجرا شود. اگر از برخی داده‌های تحت کنترل کلاینت برای اجرای زمان اتمام جلسه استفاده شود، برای مثال با استفاده از مقادیر کوکی یا سایر پارامترهای کلاینت برای ردیابی مراجع زمانی (به عنوان مثال تعداد دقایق از زمان ورود به زمان)، مهاجم می‌تواند این موارد را برای گسترش مدت‌زمان جلسه دستکاری کند. بنابراین برنامه باید سمت سرور زمان عدم فعالیت را پی‌گیری کند و پس از انقضای زمان، به طور خودکار نشست فعلی کاربر را نامعتبر کرده و هر داده ذخیره‌شده بر روی کلاینت را حذف کند.
هر دو عملکرد باید با دقت اجرا شوند تا از معرفی نقاط ضعفی که می تواند توسط مهاجم برای دسترسی غیرمجاز در صورت فراموشی خروج از برنامه مورد سوء استفاده قرار گیرد، جلوگیری شود. به طور خاص، در مورد تابع خروج از سیستم، مهم است که اطمینان حاصل شود که تمام توکن‌های نشست (به عنوان مثال کوکی‌ها) به درستی تخریب یا غیرقابل‌استفاده می‌شوند و کنترل‌های مناسب در سمت سرور اعمال می‌شوند تا از استفاده مجدد از نشانه‌های جلسه جلوگیری شود.
بررسی Logout Functionality در OWASP
اگر چنین اقداماتی به درستی انجام نشوند، مهاجم می‌تواند این توکن‌های جلسه را به منظور “بازیابی” جلسه یک کاربر قانونی و جعل هویت او، دوباره اجرا کند (این حمله معمولا به عنوان “cookie replay” شناخته می‌شود). البته، یک عامل تخفیف دهنده این است که مهاجم باید قادر به دسترسی به آن توکن‌ها باشد (که بر روی PC قربانی ذخیره شده‌اند)، اما در بسیاری از موارد، این امر ممکن است غیر ممکن یا به طور خاص دشوار نباشد.
رایج‌ترین سناریو برای این نوع حمله یک کامپیوتر عمومی است که برای دسترسی به برخی اطلاعات خصوصی استفاده می‌شود (به عنوان مثال، وب میل، حساب بانکی آنلاین). اگر کاربر بدون خروج، از رایانه دور شود و Session Timeout روی برنامه اجرا نشود، مهاجم می‌تواند با فشار دادن دکمه Back مرورگر به همان حساب دسترسی پیدا کند.
اهداف تست
این مساله را که زمان اتمام یک جلسه وجود دارد، مورد تایید قرار دهید.
چگونه تست را انجام دهیم
تست جعبه سیاه
رویکرد مشابهی که در بخش آزمایش برای logout functionality به آن پرداخته شد را می‌توان در زمان اندازه‌گیری خروج از سیستم مورد استفاده قرار داد. روش تست بسیار مشابه است. ابتدا، تست نفوذگر باید بررسی کنند که آیا یک وقفه وجود دارد یا خیر، برای مثال، با ورود به سیستم و انتظار برای خروج از سیستم.
همانند تابع خروج از سیستم، پس از گذشت زمان، تمام توکن‌های نشست باید تخریب شوند یا غیرقابل‌استفاده باشند.
سپس، اگر زمان اتمام پیکربندی شده باشد، تست نفوذگران باید بدانند که آیا زمان اتمام توسط مشتری یا توسط سرور (یا هر دو)اجرا می‌شود. اگر کوکی نشست non-persistent باشد (یا به طور کلی، کوکی نشست هیچ داده‌ای را در مورد زمان ذخیره نمی‌کند)، تست نفوذگران می‌توانند فرض کنند که اتمام زمان توسط سرور اجرا می‌شود.
اگر کوکی نشست حاوی برخی داده‌های مرتبط با زمان باشد (به عنوان مثال، زمان log in، یا آخرین زمان دسترسی، یا تاریخ انقضا برای یک کوکی persistent)، آنگاه ممکن است که کلاینت در اجرای اتمام زمان دخیل باشد. در این مورد، تست نفوذگران می‌توانند سعی کنند کوکی را اصلاح کنند (اگر از لحاظ رمزنگاری محافظت نشده باشد) و ببینند چه اتفاقی برای جلسه می‌افتد.
به عنوان مثال، تست نفوذگران می‌توانند تاریخ انقضا کوکی را در آینده تعیین کنند و ببینند که آیا جلسه می‌تواند طولانی شود یا خیر.
به عنوان یک قانون کلی، همه چیز باید در سمت سرور بررسی شود و نباید با تنظیم مجدد نشست کوکی‌ها به مقادیر قبلی، دسترسی دوباره به برنامه امکان پذیر باشد.
تست جعبه خاکستری
تست نفوذگر باید این مساله را بررسی کند که:
تابع خروج از سیستم به طور موثری تمام توکن جلسه را از بین می‌برد یا حداقل آن‌ها را غیرقابل‌استفاده می‌کند.
سرور بررسی‌های مناسبی را در مورد وضعیت جلسه انجام می‌دهد و به مهاجم اجازه می‌دهد تا شناسه‌های جلسه تخریب شده قبلی را دوباره مورد استفاده قرار دهد.
زمان اتمام نشست به درستی توسط سرور اجرا می‌شود. اگر سرور از یک زمان انقضا استفاده می کند که از یک نشانه جلسه ارسال شده توسط مشتری خوانده می شود (اما این توصیه نمی شود) ، پس توکن باید از نظر رمزنگاری در برابر دستکاری محافظت شود.
توجه داشته باشید که مهم‌ترین چیز، بی‌اعتبار کردن جلسه در سمت سرور است. به طور کلی این بدان معنی است که این کد باید روش‌های مناسب را به کار گیرد، برای مثال HttpSession.invalidat()در جاوا و Session.abandon() در .NET
پاک کردن کوکی‌ها از مرورگر توصیه می‌شود، اما به شدت ضروری نیست، زیرا اگر نشست به درستی بر روی سرور نامعتبر باشد، داشتن کوکی در مرورگر به مهاجم کمک نخواهد کرد.
