WSTG-SESS-01

بررسی Session Management Schema

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

خلاصه

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

در این تست، تست نفوذگر بررسی می‌کند که کوکی‌ها و دیگر توکن‌های جلسه به شیوه‌ای ایمن و غیرقابل‌پیش‌بینی ایجاد شده باشند. مهاجمی که قادر به پیش‌بینی و جعل یک کوکی ضعیف است، به راحتی می‌تواند جلسات کاربران قانونی را به سرقت ببرد.

کوکی‌ها برای اجرای مدیریت جلسه استفاده می‌شوند و با جزئیات در RFC ۲۹۶۵ توضیح داده می‌شوند. به طور خلاصه، زمانی که یک کاربر به یک برنامه دسترسی پیدا می‌کند که نیاز به پی‌گیری اقدامات و هویت آن کاربر در میان درخواست‌های متعدد دارد، یک کوکی (‏یا کوکی‌ها) ‏توسط سرور ایجاد شده و به مشتری ارسال می‌شود. مشتری سپس کوکی را برای تمام Connection هایی که برقرار می کند، به سرور ارسال خواهد کرد تا زمانی که کوکی منقضی شده و یا نابود شود.

داده‌های ذخیره‌شده در کوکی می‌توانند طیف وسیعی از اطلاعات در مورد این که کاربر کیست، این که او تا کنون چه اقداماتی انجام داده‌است، ترجیحات او چیست و غیره را برای سرور فراهم کنند. بنابراین ساختار State را برای یک پروتکل Stateless مانند HTTP فراهم می‌کنند.

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

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

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

معمولا مراحل اصلی الگوی حمله به شرح زیر است:

cookie collection: جمع‌آوری تعداد کافی از نمونه‌های کوکی؛
cookie reverse engineering: تحلیل الگوریتم تولید کوکی؛
cookie manipulation: جعل یک کوکی معتبر به منظور انجام حمله. این مرحله آخر ممکن است به تعداد زیادی تلاش نیاز داشته باشد، بسته به این که کوکی چگونه ایجاد می‌شود (‏cookie brute-force attack)‏.

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

اهداف تست

• توکن‌های جلسه را برای یک کاربر و برای کاربران مختلف در صورت امکان جمع‌آوری کنید.
• تجزیه و تحلیل کنید و اطمینان حاصل کنید که تصادفی بودن کافی برای جلوگیری از حملات جعل جلسه وجود دارد.
• کوکی‌ها را اصلاح کنید و اطمینان حاصل کنید که امضا (signed) نمی‌شوند و حاوی اطلاعاتی هستند که می‌توان آن‌ها را دستکاری کرد.

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

Black-Box Testing and Examples

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

• آیا همه دستورالعمل‌های Set-Cookie با Secure برچسب گذاری شده‌اند؟
• آیا عملیات مربوط به کوکی بر روی کانال رمزنگاری نشده صورت می‌گیرد؟
• آیا کوکی می‌تواند بر روی انتقال در کانال های رمزنگاری نشده Force شود؟
• اگر چنین است، برنامه امنیت را چگونه حفظ می‌کند؟
• آیا کوکی‌ها Persistent هستند؟
• زمان انقضا بر روی کوکی‌های پایدار چقدر است و آیا منطقی هستند؟
• آیا کوکی‌هایی که انتظار می‌رود گذرا (Transient) باشند به همین شکل گذرا پیکربندی شده اند؟
• از چه تنظیمات Cache-Controlدر HTTP/1.1 برای محافظت از کوکی‌ها استفاده می‌شود؟
• از چه تنظیمات Cache-Controlدر HTTP/1.0 برای محافظت از کوکی‌ها استفاده می‌شود؟

Cookie Collection

اولین گام مورد نیاز برای دستکاری کوکی درک چگونگی ایجاد و مدیریت کوکی توسط برنامه است. برای این کار، تست نفوذگر باید سعی کنند به سوالات زیر پاسخ دهند:

• چه تعدادی از کوکی‌ها توسط برنامه مورد استفاده قرار می‌گیرند؟
برنامه را مورد بررسی (Surf) قرار دهید. توجه داشته باشید که چه زمانی کوکی‌ها ایجاد می‌شوند. فهرستی از کوکی‌های دریافتی تهیه کنید، صفحه‌ای که آن‌ها را تنظیم می‌کند (‏set-cookie)‏، دامینی که آن‌ها برای آن معتبر هستند، Value آن‌ها و ویژگی‌های آن‌ها.
• کدام بخش از برنامه کوکی را تولید می‌کند یا تغییر می‌دهد؟
با دنبال کردن برنامه، متوجه شوید که کدام کوکی‌ها ثابت باقی می‌مانند و کدام یک اصلاح می‌شوند. چه رویدادهایی کوکی را تغییر می‌دهند؟
• کدام بخش از برنامه به این کوکی برای دسترسی و استفاده نیاز دارد؟
ببینید کدام قسمت از برنامه نیاز به کوکی دارد. به یک صفحه دسترسی پیدا کنید، سپس دوباره بدون کوکی و یا با یک مقدار تغییر یافته از آن به صفحه مراجعه کنید. سعی کنید یک نقشه از مکان‌هایی که از کوکی‌ها استفاده می‌کنند، تهیه کنید.
یک Mapping از هر کوکی به بخش‌های کاربردی مربوطه و اطلاعات مربوطه می‌تواند خروجی ارزشمندی از این فاز باشد.

Session Analysis

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

• ساختار توکن و نشت اطلاعات
مرحله اول بررسی ساختار و محتوای Session IDارائه‌شده توسط برنامه است. یک اشتباه رایج این است که به جای صدور یک مقدار عمومی و ارجاع داده‌های واقعی در سمت سرور، داده‌های خاصی را در توکن قرار دهیم.
اگر Session IDمتن واضحی (Clear-Text) داشته باشد، ساختار و داده‌های مربوطه ممکن است بلافاصله آشکار شوند.

به عنوان مثال:

192.168.100.1:owaspuser:password:15:58

اگر به نظر می‌رسد بخشی یا کل توکن کدگذاری یا هش شده باشد، باید با روش‌های مختلف برای بررسی و آشکار سازی آن اقدام شود. به عنوان مثال رشته 192.168.100.1:owaspuser:password:15:58 در قالب های Hex، Base64 و MD5 به صورت ها زیر نمایش داده می‌شود:

Hex:3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64: MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5: 01c2fc4f0a817afd8366689bd29dd40a

با شناسایی نوع مبهم سازی، ممکن است بتوان به داده‌های اصلی رسید. البته در اغلب موارد، این امر غیر محتمل است. با این حال، ممکن استEnumerate نوع رمزگذاری و فرمت پیام مفید باشد. علاوه بر این، اگر هر دو روش فرمت و مبهم سازی را بتوان استنتاج کرد، حملات خودکار Brute Force نیز قابل طراحی خواهند بود.

توکن‌های ترکیبی ممکن است شامل اطلاعاتی مانند آدرس IP یا User ID به همراه یک بخش کد گذاری شده باشند.

owaspuser:192.168.100.1:a7656fafe94dae72b1e1487670148412

پس از دستیابی به توکن نشست باید آن را مورد تجزیه و تحلیل قرار داد به عنوان مثال یک توکن ۳۲ بیتی ممکن است شامل ۱۶ بیت داده ایستا و ۱۶ بیت داده متغیر باشد. این مورد ممکن است نشان دهد که ۱۶ بیت اول نشان‌دهنده یک مشخصه ثابت از کاربر برای مثال نام کاربری یا آدرس IP است. اگر قطعه ۱۶ بیتی دوم در حال افزایش با نرخ منظم است، ممکن است یک عنصر ترتیبی یا حتی زمان محور را برای تولید توکن نشان دهد.

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

نواحی زیر باید در طول تست ساختار Session ID منفرد و چندگانه مورد بررسی قرار گیرند:

• چه بخش‌هایی از Session IDاستاتیک هستند؟
• چه اطلاعات محرمانه ای به صورت ClearText در Session ID ذخیره می‌شود؟ نام‌های کاربری،UID ، آدرس‌های IP و غیره.
• چه اطلاعات محرمانه ای که ذخیره شده اند به راحتی رمزگشایی می‌شوند؟
• چه اطلاعاتی را می‌توان از ساختار Session IDاستنباط کرد؟
• چه بخش‌هایی از Session IDدر لاگین های متفاوت، ثابت هستند؟
• چه الگوهای آشکاری در Session ID به عنوان یک کلیت یا بخش‌های جداگانه وجود دارد؟

Session ID Predictability and Randomness

تجزیه و تحلیل مناطق متغیر ‏ Session ID‏در صورت وجود باید برای ایجاد هر گونه الگوهای قابل‌تشخیص یا قابل‌پیش‌بینی انجام شود. این تحلیل‌ها ممکن است به صورت دستی و با ابزارهای آماری برای استنباط هر الگویی در محتوای Session IDانجام شود. چک‌های دستی باید شامل مقایسه Session ID صادر شده برای شرایط ورود یک‌سان باشد به عنوان مثال، همان نام کاربری، رمز عبور و آدرس IP .

زمان یک عامل مهم است که باید کنترل شود. برای جمع آوری نمونه ها در یک پنجره زمانی و ثابت نگه داشتن آن متغیر، باید تعداد زیادی اتصال همزمان ایجاد شود.

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

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

• آیا Session ID به طور قابل‌اثبات تصادفی است؟ آیا مقادیر حاصل شده می‌توانند باز تولید شوند؟
• آیا شرایط ورودی مشابه همان ID را در اجرای بعدی تولید می‌کند؟
• آیا Session ID به طور قابل‌اثبات نسبت به تجزیه و تحلیل آماری یا رمزی مقاوم است؟
• کدام عناصر Session ID مربوط به زمان هستند؟
• چه بخش‌هایی از شناسه نشست قابل‌پیش‌بینی هستند؟
• آیا می‌توان شناسه بعدی را با دانش کامل الگوریتم تولید و ID های قبلی استنتاج کرد؟

Cookie Reverse Engineering

اکنون که تست نفوذگر کوکی‌ها را به دست آورده است و ایده کلی استفاده از آن‌ها را دارد، وقت آن است که نگاه عمیق‌تری به کوکی‌ها داشته باشید که جالب به نظر می‌رسند. کدوم کوکی جالب به نظر می رسد؟ یک کوکی، به منظور ارائه یک روش ایمن مدیریت جلسه، باید چندین ویژگی را ترکیب کند که هر کدام از آن‌ها با هدف حفاظت از کوکی در برابر حملات مختلف انجام می‌شود.

این ویژگی‌ها در زیر خلاصه شده‌اند:

• غیرقابل‌پیش‌بینی بودن: یک کوکی باید حاوی مقدار داده سخت در برابر حدس باشد. هر چه ساختن و جعل یک کوکی معتبر سخت‌تر باشد، ورود به جلسه قانونی کاربر سخت‌تر است. اگر یک مهاجم بتواند کوکی مورد استفاده در یک جلسه فعال از یک کاربر قانونی را حدس بزند، قادر به جعل کامل آن کاربر (‏ربودن جلسه)‏ خواهد بود. به منظور غیرقابل‌پیش‌بینی کردن یک کوکی، می‌توان از مقادیر تصادفی یا رمزنگاری استفاده کرد.
• مقاومت در برابر دستکاری: کوکی باید در برابر تلاش‌های مخرب اصلاح مقاومت کند. اگر تست نفوذگر یک کوکی مانند IsAdmin=No را دریافت کند، اصلاح آن برای گرفتن حقوق مدیریت بدیهی به نظر می‌رسد، مگر اینکه برنامه یک بررسی دوگانه انجام دهد (‏به عنوان مثال، یک هش رمزگذاری شده از مقدار آن را به کوکی ارسال کند).
• انقضاء: یک کوکی حیاتی باید تنها برای یک دوره زمانی مناسب معتبر باشد و باید از دیسک یا حافظه پس از آن حذف شود تا از خطر بازپخش شدن آن جلوگیری شود. این امر در مورد کوکی‌ها که داده‌های غیر حیاتی را ذخیره می‌کنند که باید در طول جلسات به خاطر سپرده شوند ‏صدق نمی‌کند.
• فلگ Secure: کوکی که مقدار آن برای یکپارچگی جلسه حیاتی است باید این فلگ را فعال کند تا انتقال آن را تنها در یک کانال رمزگذاری شده برای جلوگیری از استراق‌سمع مجاز سازد.

رویکرد در اینجا جمع‌آوری تعداد کافی از نمونه‌های یک کوکی است و شروع به جستجوی الگوها در مقدار آن‌ها می‌باشد. معنای دقیق «کافی» می‌تواند از تعداد انگشت شماری از نمونه‌ها در صورت ساده بودن روش تولید کوکی ها تا چندین هزار مورد، در صورت نیاز به انجام برخی تحلیل‌های ریاضی متفاوت باشد.

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

جنبه دیگری که باید در نظر گرفته شود زمان است. همیشه زمان دقیقی که یک کوکی به دست آمده‌است را ثبت کنید، این احتمال وجود دارد که زمان در مقدار کوکی نقش داشته باشد (‏سرور می‌تواند از یک timestamp به عنوان بخشی از مقدار کوکی استفاده کند)‏. زمان ثبت‌شده می‌تواند زمان محلی یا timestamp سرور (یا هر دو) باشد که در پاسخ HTTP گنجانده شده‌است.

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

نمونه‌هایی از چک‌هایی که باید در این مرحله انجام شوند عبارتند از:

• چه مجموعه کاراکترهایی در کوکی مورد استفاده قرار می‌گیرد؟ عدد، حروف، عبارات هگزادسیمال؟ چه اتفاقی می‌افتد اگر تست نفوذگر کاراکترهایی که مورد انتظار نباشد را در کوکی قرار دهد؟
• آیا کوکی از بخش‌های فرعی مختلفی تشکیل شده‌است که بخش‌های مختلفی از اطلاعات را حمل می‌کنند؟ بخش‌های مختلف چگونه از هم جدا می‌شوند؟ با کدام جدا کننده؟ برخی از بخش‌های کوکی می‌توانند واریانس بالاتری داشته باشند، برخی دیگر ممکن است ثابت باشند، برخی دیگر تنها می‌توانند یک مجموعه محدود از مقادیر را در نظر بگیرند.

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

یک مثال از یک کوکی با ساختار ساده به صورت زیر است:

این مثال ۵ زمینه مختلف را نشان می‌دهد که انواع مختلفی از داده‌ها را حمل می‌کنند:

ID مقدار هگزادسیمال
CRمقدار عددی کوچک
TMو LM عدد صحیح بزرگ. (و عجیب است که ارزش یکسانی دارند. ارزش دیدن این را دارد که با اصلاح یکی از آن‌ها چه اتفاقی می افتد)
S مقدار alphanumeric

حتی زمانی که از هیچ جدا کننده ای استفاده نمی‌شود، داشتن نمونه‌های کافی می‌تواند به درک ساختار کمک کند.

Brute Force Attacks

حملات Brute Force به ناچار از پرسش‌های مربوط به قابل‌پیش‌بینی بودن و تصادفی بودن ناشی می‌شوند. واریانس در Session ID باید همراه با مدت جلسه برنامه و زمان اتمام در نظر گرفته شود. اگر تغییر در Session ID نسبتا کوچک باشد، و اعتبار ID جلسه طولانی باشد، احتمال حمله موفق Brute Force بسیار بالاتر است.

یک Session IDطولانی (یا بهتر بگوییم یک ID با واریانس زیاد) و دوره اعتبار کوتاه‌تر، موفقیت در حمله Brute Force را بسیار سخت‌تر می‌کند.

• حمله Brute Force به تمام Session ID ممکن چه مدت طول می‌کشد؟
• آیا فضای Session IDبه اندازه کافی بزرگ است تا از اعمال Brute Force جلوگیری کند؟
• برای مثال، آیا طول کلید در مقایسه با طول عمر معتبر کافی است؟
• آیا تاخیر بین تلاش‌های اتصال با ID های جلسه مختلف خطر این حمله را کاهش می‌دهد؟

Gray-Box Testing and Example

اگر تست نفوذگر به پیاده سازی طرح مدیریت جلسه دسترسی داشته باشد، می‌تواند موارد زیر را بررسی کند:

• توکن نشست تصادفی
شناسه نشست یا کوکی صادر شده به مشتری نباید به راحتی قابل‌پیش‌بینی باشد (از الگوریتم های خطی براساس متغیرهای قابل‌پیش‌بینی مانند آدرس IP مشتری استفاده نکرده باشد) استفاده از الگوریتم های رمزنگاری با طول کلید ۲۵۶ بیت مانند AES توصیه می‌شود.

• طول توکن
Session ID باید حداقل ۵۰ کاراکتر طول داشته باشد.

• Session Time-out
توکن نشست باید یک زمان – خروج تعریف‌شده داشته باشد (‏این زمان به حساسیت داده‌های مدیریت برنامه بستگی دارد)‏.

• پیکربندی کوکی:
non-persistent: تنها در حافظه RAM
Secure Flag: (تنها در کانال HTTPS تنظیم شده‌است)

Set-Cookie: cookie=data; path=/; domain=.aaa.it; secure

تنظیم HTTPOnly Flag: (عدم دسترسی به کوکی از طریق اسکریپت)

Set-Cookie: cookie=data; path=/; domain=.aaa.it; HttpOnly

ابزارها

ZAP
Burp Sequencer
YEHG’s JHijack

مراجع

• RFC 2965 “HTTP State Management Mechanism”
• RFC 1750 “Randomness Recommendations for Security”
• Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis” (2001)
• Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis – One Year Later” (2002)
• Correlation Coefficient
• ENT
• DMA[2005-0614a] – ‘Global Hauri ViRobot Server cookie overflow’
• Gunter Ollmann: “Web Based Session Management”
• OWASP Code Review Guide