دوره SEC542 – بخش هفدهم

در این بخش از دوره SEC542 شما با ادامه مبحث Session در وب آشنا خواهید شد و نحوه استفاده و کاربرد آن در وب را فرا خواهید گرفت.

دیدگاه مهاجم به Session State

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

ابزارهای متعددی برای حمله به session استفاده می‌شود. Intercept کردن درخواست‌ها در پراکسی، امکان دسترسی به session ها را برای ما فراهم می‌کند. همچنین اسکریپت‌هایی جهت brute force نمودن session ID ها وجود دارد.

تغییر session ID می‌تواند منجر به موارد زیر گردد:

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

جمع آوری Session Token ها

اکثر وب‌اپلیکیشن‌ها برای ردیابی و دنبال کردن کاربر در یک زنجیره از تعاملات، از session استفاده می‌کنند. در همان حال که ما در یک سایت می‌گردیم، اپلیکیشن برای ما session هایی مختلفی می‌سازد. اما session به چه معناست؟ در میان بسیاری از کانکشن‌های متفاوت TCP، مفهوم session بصورت هر ترکیب از کوکی، پارامترهای URL، فیلدهای پنهان فرم و اطلاعات IP یا مرورگر، معنا پیدا می‌کند.

اگر بتوانیم منطق پشت ایجاد و حفظ session state را دریابیم، آنگاه ممکن است بتوانیم آن را دستکاری کرده و به اپلیکیشن حمله کنیم.
به عنوان یک مثال ساده از session، یک کوکی به نام USERID را در نظر بگیرید. اگر به کوکی USERID خود نگاه کردید و دیدید که اسم شما را با فرمت Fullname.Lastname نوشته است، آنگاه ممکن است با اصلاح مقدار کوکی به “Arthut.Dent”، اکانت کاربر “Arthur Dent” به شما اختصاص داده شود.

دوره SEC542 و آموزش Session در وب

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

اما در مورد کوکی USERID با مقدار S2V2aW4gSm9obnNvbg== چطور؟ یا مقدار 72b28b1b696ecaadfc0f212f16809850 و یا 655609cdf4d93495c9f3166e6d ؟ اگر این مقادیر، خروجی انکد شده Base64، md5sum و انکد شده hex برای پسورد “abcdefg” بودند، باز هم امکان دستکاری آن‌ها و تغییر مقدارشان به توکن‌های جدید وجود داشت.

معمولا ارسال مکرر درخواست‌های جدید (بدون اطلاعات session) به صفحه لاگین اپلیکیشن با استفاده از ابزارهایی چون Wget، Python یا Netcat موجب می‌شود تا اپلیکیشن هر بار یک session ID جدید تولید کند. باید به دنبال یافت الگو در session ID های تولید شده باشید.

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

• دستی
• اسکریپت‌های customize شده
• ابزار Burp Suite

متغیرهای Session Token

اغلب پیش می‌آید که وب‌اپلیکیشن از چندین تکنیک جهت ردیابی session state بین درخواست‌ها استفاده کند. این تکنیک‌ها ممکن است در صفحات مجزا و یا حتی در یک صفحه خاص پیاده شوند. مثلا ممکن است از تکنیک ارسال توکن با پارامترهای URL از طریق متد HTTP GET استفاده شود:

http://test.com/index.php?jsessionid=dYvCMH1cxEc

همچنین ممکن است از فیلدهای پنهان فرم استفاده شود. مانند متغیر ViewState:

تکنیک آخر، استفاده از کوکی است. در زیر پاسخ HTTP را می‌بینید که با هدر Set-Cookie، کوکی JSESSIONID را به کاربر اختصاص می‌دهد:

HTTP/1.1 200 Ok
Date: Sat, 20 Dec 2008 14:33:11 GMT
Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000ckr17XBEsqgOifzDmOiZbi; Path=/

شناسایی توکن های Session

یکی از گام هایی که باید برداشته شود شناسایی متد انتقال وضعیت session است. بعضی از ابزارها مانند Burp و w3af این کار را برای ما انجام می‌دهند اما همیشه در این راه موفق نیستند. ما باید به دنبال شناسه‌های شناخته شده و رایج‌تر session ها باشیم مانند PHPSESSIONID در PHP و یا JSESSIONID در جاوا.

همچنین برخی از نام‌های رایجی که برای session ها استفاده می‌شود عبارتند از: session، sessionId و یا sid . سایر نام‌ها را می‌توانید در گوگل سرچ کنید.

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

قابل پیش بینی بودن توکن Session

قابل پیش‌بینی بودن توکن session مشکلی جدی است. اگر در یک اپلیکیشن، توکن قابل پیش‌بینی باشد، مهاجم می‌تواند حدس بزند چه توکن‌هایی تا الان استفاده شده‌اند و آن‌ها را hijack کند تا به یک session فعال دست یابد.

توکن‌های زیر را در نظر بگیرید. مقدار این توکن‌ها به صورت ترتیبی زیاد می‌شود:

اولین لاگین: 74eb2cd93f2a95ba
لاگین بعدی: 74eb2cd93f2a95bb
لاگین بعدی: 74eb2cd93f2a95bc
لاگین بعدی: 74eb2cd93f2a95bf

همانطور که می‌بینید در دو لاگین آخر، بین توکن‌ها اختلافی بیشتر از یک عدد وجود دارد. چرا؟

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

توکن‌ها ممکن است بر اساس یک الگوریتم خاص عوض شوند. مثلا هر توکن به اندازه یک مقدار ثابت با توکن قبل اختلاف داشته باشد.

42 , 84 , 126 , 168 , …

به توکن‌های زیر دقت کنید. آیا می‌توانید الگوریتم آن‌ها را حدس بزنید؟

c4ca4238a0b923820dcc509a6f75849b
c81e728d9d4c2f636f067f89cc14862c
eccbc87e4b5ce2fe28308fd9f2a7baf3
a87ff679a2f3e71d9181a67b7542122c

این توکن‌ها مقادیر هش شده (با الگوریتم md5) برای اعداد اسکی 1 تا 4 هستند. در بالا مقادیر md5sum(1) ، md5sum(2) ، md5sum(3) و md5sum(4) قابل مشاهده‌اند.

همچنین دیده شده است که اگر برنامه نویسان بخواهند توکن خاص خود را تولید کنند، اغلب از دیتای کلاینت مانند آدرس IP به عنوان توکن استفاده می‌کنند. معمولا این دیتا رمز و یا هش می‌شود ولی ما باید بتوانیم آن را در تست‌های خود شناسایی کنیم.

جمع آوری Session Credentials بصورت دستی

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

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

برای حفظ توکن‌ها در این روش، تمامی session های دریافت شده در حین کار با سایت را در یک فایل flat و یا یک spreadsheet ذخیره کنید. سپس آن‌ها را به کمک Excel و یا ماشین حساب آنالیز نمائید.

جمع‌آوری Session Credentials به کمک اسکریپت‌های customize شده

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

این فایل می‌تواند با ابزارهای spreadsheet مانند Excel آنالیز شده و جداول و گراف‌هایی مانند ابزار Burp تولید کند.

مطالب این بخش توسط سرکار خانم فهیمه رضایی تهیه شده است.