دوره تست نفوذ وب سطح متوسط – بخش چهاردهم

در این بخش از دوره آموزشی تست نفوذ سطح متوسط که برگرفته از دوره SEC642 می باشد به مبحث آشنایی با Cross Site Request Forgery می پردازیم.

Cross Site Request Forgery Review

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

Cross Site Request Forgery Concerns

نگرانی‌هایی در مورد XSRF وجود دارد. بسیاری از آن‌ها مشابه یا نگرانی‌های XSS هستند زیرا هر دوی این حملات بر اجرا در Context کاربر تمرکز دارند. همانطور که ما با مشتریان و کاربران صحبت می‌کنیم، معمولا متوجه می‌شویم که XSRFنادیده گرفته می‌شود یا حتی در مورد آن چیزی نمی‌دانند. برخی نمی‌دانند که حمله چیست و چه کاری می‌تواند انجام دهد. بنابراین همانطور که تست‌های خود را انجام می‌دهیم، باید اطمینان حاصل کنیم که مشکل چیست و چرا هدف باید در مورد آن نگران باشد.

از طرف دیگر نگرانی ما Transaction ها می‌باشد. ما باید اطمینان حاصل کنیم که Transaction ها، حساس هستند. بسیاری از سازمان‌ها نگران این نیستند که فیلد Search مستعد XSRF است، اما باید به آن‌ها نشان داد که یک کاربر می‌تواند داده‌ها یا پول را از حساب دیگری بدزدد. برای انجام صحیح این کار، شما باید درک کنید که چه چیزی برای سازمان حساس است.

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

توصیه‌هایی برای اصلاح فرمت درخواست از طریق سایت را می‌توان در وب سایت OWASP یافت:

cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Detecting CSRF

تشخیص XSRF نسبت به XSS دشوارتر است زیرا بر صفحاتی تکیه دارد که بخشی از برنامه سمت سرور نیستند. در این زمان، آسیب‌پذیری XSRF به طور دقیق توسط اسکنرهای خودکار تشخیص داده نمی‌شود و بنابراین نیاز به شناسایی به صورت دستی دارد.

به منظور شناسایی آسیب پذیری XSRF از یک فرآیند چهار مرحله‌ای در برنامه استفاده کنید:

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

۲. یک سند HTML ایجاد کنید که حاوی یک tag ارجاع داده‌شده به صفحه حساس باشد.

۳. بعد از ورود به برنامه، به سند ایجاد شده دسترسی پیدا کنید و بررسی نمایید که تابع مورد نظر اجرا شده است یا خیر.

Post – Based Request Code

تصویر بالا فایل HTML ای را نشان می‌دهد که ما برای load کردن حمله مبتنی بر فرم در مرورگر قربانی استفاده می‌کنیم. این شکل شامل دو پارامتر مورد استفاده در تراکنش آسیب‌پذیر است که یکی acctnum و دیگری amount است. در این مثال به یک تابع انتقال پول بانک حمله می‌شود.

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

Ajax Exploitation

یک نسخه اکسپلویت دیگر، استفاده از آبجکتی به نام XMLHTTPRequest از AJAX است. یکی از دلایل اصلی این امر این است که کاربران انتظار دارند وب سایت‌ها درخواست AJAX را به سرورهای مختلف ارسال کنند و متوجه نمی‌شوند که چه زمانی این اتفاق می‌افتد. از آنجا که ما می‌توانیم هر آنچه که جاوا اسکریپت نیاز به انجام حملات پیشرفته دارد را بنویسیم، XHR ما را قادر می‌سازد تا کارهایی مانند تنظیم هدرهای درخواست برای رسیدگی به موارد خاص مانند بررسی referer انجام دهیم تا دقیقاً از حمله‌ای که انجام می‌دهیم جلوگیری کنیم.

البته، ما باید به خاطر داشته باشیم که Same Origin Policy می‌تواند ما را از خواندن پاسخ برنامه قربانی باز دارد. اما ما به طور معمول نیازی به دانستن پاسخ نداریم زیرا XSRF ما را ملزم می‌کند که فقط تراکنش را انجام دهیم. البته،XHR هنوز هم این قابلیت را دارد که بداند آیا حمله موفق بوده‌است یا خیر. همانطور که در بخش بعدی نشان‌داده شده‌است، ما می‌توانیم Event Listener ای را ایجاد کنیم که رویدادهایی را می‌پذیرند که ما را در صورت موفقیت تراکنش آگاه می‌کنند.

Ajax – Based Request Code

همانطور که در این نمونه کد نشان‌داده شده‌است، ما ajaxFunction را ایجاد می‌کنیم – که در آن ما درخواست POST را برای تراکنش آسیب‌پذیر ایجاد می‌کنیم. در ادامه قسمت‌های اصلی این کد را بررسی می‌کنیم.

اول، ما یک شی XHR جدید را با استفاده از xmlHTTP=new XMLHTTPRequest()ایجاد می‌کنیم و سپس یک شی FormData جدید برای نگه داشتن پیلود POST ایجاد می‌کنیم. ما از متد .append() برای اضافه نمودن دو پارامتر POST استفاده می‌کنیم. پس از آن، با استفاده از شی XHR، ما یک load و یک Error Listener ایجاد می‌کنیم. این جایی است که ما تعیین می‌کنیم آیا معامله موفقیت‌آمیز بوده‌است یا خیر. ما سپس از متدهای .open و .send برای ایجاد و ارسال درخواست استفاده می‌کنیم.

ما هم به جاوا اسکریپت و هم به XHR نیاز داریم تا از XSRF در تمرین بعدی بهره‌برداری کنیم.

Combining XSS and CSRF

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

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

Automating the Attack

XSRF نیاز دارد که کاربر یک جلسه فعال در برنامه داشته باشد. این یکی از دلایلی است که مردم این آسیب‌پذیری را کم اهمیت می‌دانند. البته باید به این نکته اشاره نمود که یافتن یک جلسه فعال آنقدرها که به نظر می رسد سخت نیست. بسیاری از برنامه‌ها دارای بازه‌های timeout طولانی هستند و یا اینکه کاربر یک زبانه باز یا پنجره مرورگر را حفظ می‌کند که به نگهداری نشست ادامه می‌دهد. البته برنامه هایی نیز وجود دارند که به طور خودکار خود را refresh می‌کنند و جلسات را به طور نامحدود ادامه می‌دهند!

بنابراین اگر XSS و XSRF را با هم ترکیب کنیم، می‌توانیم این حمله را خودکار کنیم. ما کد XSS را به برنامه تزریق می‌کنیم. اجرای پیلود XSS به این معنی است که قربانی در حال بازدید از سایت است. این بدان معنی است که جلسه فعال است و می‌تواند مورد سو استفاده قرار گیرد!

این امر یکی از استدلال‌های اصلی که استفاده از XSRF سخت است را حذف می‌کند.

Bypassing Anti CSRF

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

خوشبختانه،XSS می‌تواند این مشکل را حل کند. از آنجا که نقص XSS ما را قادر می‌سازد تا کدهایی را تزریق کنیم که در Same Origin Policy اجرا می‌شوند، می‌توانیم آن کد را کنترل کنیم. اگر ما کدی را تزریق کنیم که توکن یا مقدار تصادفی را بخواند و سپس آن را به بخشی از درخواست تبدیل کند، ما برنده می‌شویم.

Self – Replicating Exploit

از آنجا که ما یک نقص در یک برنامه داریم که ما را قادر می‌سازد تا اکسپلویت های XSS و XSRF را ترکیب کنیم، می‌توانیم حملات self-riplication را ایجاد کنیم. ما کد XSS ای را تزریق می کنیم که هنگام بازدید کاربر فعال، اجرا می‌شود. زمانی که این کد اجرا می‌شود، به نقص XSRF در تراکنش حمله می‌کند. کد XSS از عیب XSRF برای ارسال تراکنشی که حاوی کد XSS است، استفاده می‌کند. هنگامی که از این کد جدید بازدید می‌شود، فرآیند تکرار می‌شود.

برای مثال، اگر یک انجمن (Forum) را در نظر بگیرید که در برابر XSS و XSRF آسیب‌پذیر است و شما می‌توانید پیامی را ارسال کنید که حاوی کد XSS است. سپس این کد XSS پیغام جدیدی را ارسال می‌کند که حاوی کد XSS است. سپس این فرآیند تا زمانی ادامه می‌یابد که افراد در حال بازدید از انجمن هستند یا ادمین پیام‌های خاطی را حذف ‌کند. یک مثال کلاسیک از این موضوع، کرم SAMY بود که توسط سامی کامکار ایجاد شد.

CSRF and XSS Redux

با تغییر پیلود XSRF به یک اکسپلویت XSS که به یک کپی از کد XSRF اشاره می‌کند، می‌توانید یک کرم ایجاد کنید. راه‌های زیادی برای انجام این کار وجود دارد.