در این چالش، شما با یک پرتال سازمانی روبهرو هستید که از یک لایه نشست قدیمی برای مدیریت وضعیت کاربران استفاده میکند. از همان ابتدای تعامل با برنامه، نشانهها حاکی از آن هستند که مسئله اصلی به نحوه ایجاد، نگهداری و انتقال session میان مراحل قبل و بعد از احراز هویت مربوط میشود.
هدف شما در این سناریو، بررسی این است که آیا برنامه پس از ورود کاربر، شناسه نشست را بهدرستی بازتولید و جایگزین میکند یا اینکه همان نشست اولیه را همچنان معتبر نگه میدارد.
در طول تحلیل، لازم است رفتار برنامه را هم در وضعیت unauthenticated و هم پس از login با دقت بررسی کنید.
برخی صفحات داخلی و بخشهای مرتبط با session audit و status review، سرنخهایی درباره زمان ایجاد session، نحوه استفاده از browser state و ارتباط میان نشستهای اولیه و دسترسیهای بعدی ارائه میکنند. بنابراین، این چالش بیش از هر چیز بر مشاهده دقیق چرخه عمر session و درک پیامدهای امنیتی عدم rotation پس از احراز هویت تمرکز دارد.
همچنین انتظار میرود شرکتکننده تنها به رابط کاربری بسنده نکند و منطق پشت جریانهای کاری خاص برنامه را نیز از منظر امنیتی تحلیل کند.
بعضی قابلیتها یا مسیرهای داخلی ممکن است بر این فرض تکیه داشته باشند که مرورگر هنوز در وضعیت احرازنشده قرار دارد، و همین موضوع میتواند در صورت مدیریت نادرست نشست، به یک ضعف منطقی تبدیل شود. در نتیجه، بررسی تفاوت میان browser jarهای مجزا، وضعیت session در مراحل مختلف و نحوه انتقال trust میان workflowهای برنامه، بخش مهمی از این سناریو خواهد بود.
این چالش در اصل برای سنجش درک شما از یکی از ضعفهای رایج مدیریت نشست، یعنی Session Fixation، طراحی شده است.
اگر بتوانید رفتار برنامه را مرحلهبهمرحله و در بستر جریانهای واقعی آن ارزیابی کنید، متوجه خواهید شد که مسئله اصلی نه در یک باگ ظاهری، بلکه در اعتماد نادرست به شناسه نشستی نهفته است که پیش از authentication ایجاد شده است.
از این رو، رویکرد مناسب در این چالش، تحلیل دقیق lifecycle نشست، بررسی نقاط تغییر سطح دسترسی و ارزیابی امنیتی نحوه تثبیت یا بازتولید session در برنامه است.
این چالش توسط PingQueen طراحی شده است.
همچنین جهت دسترسی به صفحه مربوط به آزمایشگاه WSTG می توانید به لینک زیر مراجعه نمایید:
درصد پیشرفت حل چالش
0%
