WSTG-SESS-04

بررسی Exposed Session Variables

در این بخش از دوره آموزشی OWASP-WSTG به ششمین بخش از استاندارد WSTG با شناسه WSTG-SESS-04 می پردازیم که مربوط به بررسی Exposed Session Variables می باشد.

خلاصه

توکن‌های جلسه (Cookie, SessionID, Hidden Field)، در صورت در معرض قرار گرفتن، معمولا یک مهاجم را قادر می‌سازد تا هویت یک قربانی را جعل کند و به صورت غیر قانونی به برنامه دسترسی داشته باشد. مهم است که آن‌ها در همه زمان‌ها به خصوص در حین انتقال بین مرورگر مشتری و سرورهای برنامه، از استراق‌سمع محافظت شوند.

اطلاعات موجود در این بخش، به جای داده های عمومی، به نحوه اعمال امنیت حمل و نقل برای انتقال داده های Session ID مربوط می شود و ممکن است سخت تر از سیاست های ذخیره سازی و انتقال اعمال شده برای داده های ارائه شده توسط سایت باشد.

با استفاده از یک Personal Proxy، می توان موارد زیر را در مورد هر درخواست و پاسخ مشخص کرد:

• پروتکل مورد استفاده (‏برای مثال HTTP در مقابلHTTPS)
• HTTP Headers
• بدنه پیغام (برای مثال،POST یا محتوای صفحه)

هر بار که داده‌های Session IDبین مشتری و سرور عبور داده می‌شود، پروتکل، Cache و دستورها حریم خصوصی و بدنه باید مورد بررسی قرار گیرند.

امنیت حمل و نقل در اینجا به SessionIDهای ارسال شده در درخواست‌های GET یا POST، بدنه پیام، یا سایر موارد بر روی درخواست‌های HTTP معتبر اشاره دارد.

اهداف تست

• اطمینان حاصل کنید که رمزنگاری مناسب اجرا شده‌است.
• پیکربندی Caching را بررسی کنید.
• امنیت کانال و روش‌ها را ارزیابی کنید.

چگونه تست را انجام دهیم

Testing for Encryption & Reuse of Session Tokens Vulnerabilities

حفاظت از استراق‌سمع، اغلب توسط رمزگذاری SSL فراهم می‌شود، اما ممکن است دیگر Tunneling یا رمزگذاری را نیز شامل شود. لازم به ذکر است که رمزگذاری یا درهم سازی (Hashing) Session IDباید به طور جداگانه از رمزگذاری انتقال در نظر گرفته شود، زیرا خود Session IDدر حال محافظت است، نه داده‌ای که ممکن است توسط آن نشان داده شود.

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

توجه داشته باشید که اگر عنصری در سایت وجود دارد که در آن کاربر با شناسه‌های جلسه ردیابی می‌شود اما امنیت وجود ندارد (مثلاً توجه داشته باشید که کاربر ثبت‌شده کدام اسناد عمومی را دانلود می‌کند) ضروری است که از شناسه جلسه دیگری استفاده شود. بنابراین Session IDباید به عنوان کلیدهای مشتری از عناصر امن به عناصر غیر ایمن برای اطمینان از استفاده از یک کلید متفاوت مانیتور شود.

هر بار که احراز هویت موفقیت آمیز است، کاربر باید انتظار دریافت موارد زیر را داشته باشد:

• یک نشانه جلسه متفاوت
• هر بار که درخواست HTTP می دهند، یک توکن از طریق کانال رمزگذاری شده ارسال می شود.

Testing for Proxies & Caching Vulnerabilities

همچنین هنگام بررسی امنیت برنامه، پروکسی ها باید در نظر گرفته شوند. در بسیاری از موارد، مشتریان از طریق شرکت‌های بزرگ، ISP، یا سایر پروکسی ها یا Gateway های دیگر (‏به عنوان مثال، فایروال ها)‏ به این برنامه دسترسی خواهند داشت. پروتکل HTTP دستورالعمل‌هایی را برای کنترل رفتار Downstream Proxiy ها را فراهم می‌کند و اجرای صحیح این دستورالعمل‌ها نیز باید ارزیابی شود.

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

آشنایی با آسیب پذیری Session Fixation

برنامه همچنین باید طوری تنظیم شود که داده‌ها را در Cache در هر دو پروتکل HTTP نسخه 1.0 و 1.1 ایمن نماید.

پروتکل HTTP نسخه 1.1 تعدادی از مکانیزم‌های کنترل Cache را فراهم می‌کند. Cache-Control: no-cache نشان می‌دهد که یک پروکسی نباید از هیچ داده‌ای استفاده مجدد کند. در حالی که Cache-Control: Private به نظر می‌رسد که یک دستور مناسب باشد، این امر همچنان به یک پروکسی غیر اشتراکی (non-shared proxy) اجازه می‌دهد تا داده‌ها را Cache کند. در مورد وب کافه‌ها (web-cafes) یا سایر سیستم‌های مشترک، این یک خطر آشکار است. حتی با ایستگاه‌های کاری تک کاربره، شناسه جلسه ذخیره شده ممکن است از طریق به خطر انداختن سیستم فایل، در معرض دید قرار گیرد. Cache های پروتکل HTTP نسخه 1.0 دستور Cache-Control: no-cache را نمی شناسند.

دستورات Expires: 0 و Cache-Control: max-age=0 می بایست برای اطمینان بیشتر در مورد اینکه داده ها Cahce نمی شوند مورد استفاده قرار گیرند.

هر Request/Response ای که داده‌های Session ID را ارسال می کند باید مورد بررسی قرار گیرد تا اطمینان حاصل شود که دستورهای Cache مناسب برای آن‌ها در حال استفاده می‌باشد.

Testing for GET & POST Vulnerabilities

به طور کلی، درخواست‌های GET نباید جهت ارسال Session ID ها مورد استفاده قرار گیرند، زیرا ممکن است Session ID در لاگ‌های پروکسی یا فایروال قابل مشاهده باشد. همچنین به راحتی می‌توان آن‌ها را نسبت به انواع دیگر روش های حمل و نقل دستکاری کرد. البته باید توجه داشت که تقریبا هر مکانیزمی را می‌توان توسط مشتری با ابزارهای مناسب دستکاری کرد. علاوه بر این، حملات Cross Site Scripting (XSS) به راحتی با ارسال یک لینک ساخته‌شده خاص به قربانی مورد بهره‌برداری قرار می‌گیرند. اگر داده‌ها به صورت POST از سمت کلاینت فرستاده شوند این احتمال کم‌تر خواهد بود.

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

اگر login.asp به خوبی پیاده سازی نشده باشد، ممکن است بتوان با استفاده از URL زیر وارد سیستم شد:

owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678

اسکریپت‌های سمت سرور که به طور بالقوه نا امن ایجاد شده اند ممکن است با بررسی هر درخواست POST به این روش شناسایی شوند.

Testing for Transport Vulnerabilities

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

• Session ID ها چگونه منتقل می‌شود؟ به عنوان مثال، GET، POST، فیلد فرم (‏شامل فیلدهای مخفی)
• ‏آیا Session ID ها همیشه بر روی کانال‌های رمز شده به طور پیش‌فرض ارسال می‌شوند؟
• آیا امکان دستکاری برنامه برای ارسال Session ID رمزنگاری نشده وجود دارد؟ برای مثال، با تغییر HTTP به HTTPS؟
• چه دستورالعمل‌های cache-control برای Request/Response های در حال عبور دارای شناسه نشست اعمال می‌شود؟
• آیا این دستورها همیشه وجود دارند؟ اگر نه، استثناها کجا هستند؟
• آیا درخواست GET ای وجود دارد که شامل Session ID باشند؟
• اگر از POST استفاده شود، آیا می توان آن را با GET تغییر داد؟