بررسی ماژول Autorize در نرم افزار Burp Suite

برای محافظت از دارایی‌های آنلاین، تست امنیتی برنامه‌های تحت وب یکی از ارکان اساسی در فرآیند ایمن‌سازی آن‌ها محسوب می‌شود. ابزار Burp Suite سال‌هاست که به‌عنوان یکی از پیشروترین پلتفرم‌ها در این حوزه شناخته می‌شود و همچنان توسط کارشناسان امنیت سایبری و هکرهای کلاه‌سفید (Ethical Hackers) به‌طور گسترده مورد استفاده قرار می‌گیرد.

در میان افزونه‌های مختلفی که در جامعه‌ی تست امنیت وب کاربرد دارند، Autorize یکی از افزونه‌هایی است که به‌طور ویژه مورد توجه قرار گرفته است. این افزونه با ارائه مجموعه‌ای قدرتمند از قابلیت‌ها، فرآیند ارزیابی احراز هویت (Authentication) و کنترل دسترسی (Authorization) را ساده‌تر و مؤثرتر می‌سازد.

Autorize امکانات پیشرفته‌ای در اختیار متخصصین امنیت قرار می‌دهد که به آن‌ها اجازه می‌دهد بررسی‌های دقیق‌تری روی سیاست‌های دسترسی کاربران و ضعف‌های احتمالی مانند Broken Access Control، IDOR و سایر سناریوهای سوءاستفاده از سطوح دسترسی انجام دهند.

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

آسیب‌پذیری‌های رایج شناسایی‌شده توسط Autorize

• درک عملکرد
• نصب و راه‌اندازی
• گزینه‌های پیکربندی
• نمایش عملی عملکرد Autorize

آسیب‌پذیری‌های رایج شناسایی‌شده توسط Autorize

در ابتدا، Autorize بر شناسایی آسیب‌پذیری‌های مرتبط با Authorization تمرکز دارد. این ابزار به شناسایی چند نوع اصلی از آسیب‌پذیری‌ها کمک می‌کند، از جمله:

  کنترل دسترسی مبتنی بر نقش (RBAC) ناکافی:
Autorize مشکلاتی را شناسایی می‌کند که در آن نقش‌ها یا مجوزهای کاربر به‌درستی اعمال نمی‌شوند و این امکان را به کاربران می‌دهد که به قابلیت‌ها یا داده‌های حساسی که نباید دسترسی داشته باشند، دسترسی پیدا کنند.

  کنترل دسترسی شکسته (Broken Access Controls):
مواردی را شناسایی می‌کند که در آن کنترل‌های دسترسی به درستی عمل نمی‌کنند و منجر به دسترسی غیرمجاز به منابع یا عملیات می‌شوند.

  ارجاع مستقیم ناایمن به اشیاء (Insecure Direct Object References – IDOR):
سناریوهایی را شناسایی می‌کند که در آن مهاجمان با دستکاری ورودی می‌توانند به داده‌های کاربران دیگر یا عملیات محدود دسترسی پیدا کنند.

  مرور اجباری (Forced Browsing):
موقعیت‌هایی را نشان می‌دهد که در آن مهاجمان با دسترسی مستقیم به URLهای محدود، از محدودیت‌ها عبور می‌کنند.

  مجوزدهی ناکافی (Insufficient Authorization):
ضعف در اعمال مجوزهای کاربر را افشا می‌کند که در نتیجه آن، انجام عملیات غیرمجاز امکان‌پذیر می‌شود.

  افزایش سطح دسترسی افقی و عمودی (Horizontal and Vertical Privilege Escalation):
نقص‌هایی را کشف می‌کند که به مهاجمان اجازه می‌دهد هویت کاربران دیگر را جعل کرده یا دسترسی‌های بیشتری به‌دست آورند.

  نقص‌های منطق تجاری (Business Logic Flaws):
Autorize دست‌کاری در جریان کاری (workflow) را شناسایی می‌کند که منجر به فعالیت‌های غیرمجاز یا نشت داده می‌شود.

درک عملکرد Autorize
اکنون بیایید نحوه عملکرد Autorize را بررسی کنیم. فرض کنید یک برنامهٔ وب از Role-Based Access Control و Cookie-Based Authentication استفاده می‌کند.

• کاربر عادی (Normal User):
  به قابلیت‌های عمومی دسترسی دارد، اما نمی‌تواند به قابلیت‌های مدیریتی دسترسی پیدا کند یا پایگاه داده را تغییر دهد (فقط دارای دسترسی read-only است).
• کاربر مدیر (Admin User):
  به تمام بخش‌ها دسترسی دارد و دارای مجوز کامل برای خواندن و نوشتن (full read/write permissions) است.

می‌توانید cookies مربوط به کاربر عادی را استخراج کرده و در Autorize وارد کنید. سپس، مجدداً به‌عنوان کاربر مدیر (admin user) وارد شوید، به قابلیت‌های ویژه مدیر دسترسی پیدا کرده و پایگاه داده را به‌روزرسانی کنید.

در این مرحله، Autorize چه کاری انجام می‌دهد؟ این ابزار هر درخواست را ره‌گیری می‌کند، cookies مربوط به مدیر را با cookies کاربر عادی جایگزین کرده و آن را به سرور ارسال می‌نماید. اگر پاسخ سرور همان پاسخ مورد انتظار برای مدیر باشد (مانند کد پاسخ ۲۰۰ OK) و هیچ خطایی ظاهر نشود، Autorize آن درخواست را به‌عنوان Red Bypass! علامت‌گذاری می‌کند. در مقابل، درخواست‌هایی که به‌درستی محافظت شده‌اند، به‌صورت Green Enforced! نمایش داده می‌شوند.

علاوه‌براین، برای هر درخواستی که از سمت کاربر ارسال می‌شود، Autorize تست خودکار انجام می‌دهد. در برنامه‌های بزرگ که دارای بیش از ۳۰ صفحهٔ پویا هستند، این ویژگی فرایند تست را به‌شدت ساده‌تر می‌کند. چرا که با توجه به تعداد زیاد URLها، بررسی دستی بسیار زمان‌بر خواهد بود؛ اما Autorize بخش زیادی از بار کشف آسیب‌پذیری را بر عهده می‌گیرد.

به‌طور مشابه، Autorize مشکلات موجود در API endpoints را نیز به همین روش شناسایی می‌کند. باید روش authentication برای هر API بررسی شود. به‌عنوان مثال، اگر یک API از JWT token استفاده می‌کند، می‌توانید authorization header را تغییر دهید تا آسیب‌پذیری‌های مربوط به دور زدن مجوز در API شناسایی شوند.

نصب و راه‌اندازی

از Bapp Store می‌توانید افزونه را دانلود و نصب کنید. در بخش Extensions، گزینه Bapp Store را انتخاب کنید. می‌توانید عبارت ‘Authorize’ را جستجو کنید یا به‌سادگی در لیست پایین بروید. روی آن کلیک کنید و به سمت راست صفحه اسکرول کنید.

این افزونه با Python توسعه داده شده است و مشاهده خواهید کرد که پیش از استفاده، نیاز است Jython نصب شود.

لینک زیر را مرور کرده و فایل ‘Jython Standalone’ را دانلود کنید.

پس از دانلود، به مسیر Setting > Extension بروید و در بخش سمت راست، زیر Python Environment، فایل Jython را مرور (browse) کنید و انتخاب نمایید. به این ترتیب محیط برای استفاده از Jython به‌صورت موفقیت‌آمیز تنظیم و راه‌اندازی شده است.

برنامه Burp را مجدداً راه‌اندازی کنید و مسیر زیر را برای نصب Authorize از BApp Store دنبال نمایید. مشاهده خواهید کرد که دکمه install فعال شده است. می‌توانید روی آن کلیک کرده و افزونه را نصب کنید.

پس از نصب موفقیت‌آمیز، تب Authorize در نوار بالای برنامه ظاهر خواهد شد.

گزینه‌های پیکربندی

در بخش Authorize دو تب وجود دارد: اولین تب Request/Response Viewers و تب دوم Configuration است.

Request/Response Viewers
تب Request/Response اطلاعات کامل مربوط به هر درخواست که درون Authorize ضبط و انتخاب می‌کنید، نمایش می‌دهد. درخواست‌های تغییر‌یافته در بخش Modified Request نمایش داده می‌شوند؛ تب Original Request درخواست اصلی و بدون تغییر را نمایش می‌دهد؛ و بخش Unauthenticated Request درخواست‌های بدون احراز هویت را نشان می‌دهد.

گزینه‌های پیکربندی
در تب Configuration مشاهده خواهید کرد که Autorize به‌صورت پیش‌فرض خاموش است. زمانی که آماده ضبط (capture) درخواست‌ها شدید، ابتدا باید Autorize را روشن کنید. همچنین گزینه‌هایی برای پیکربندی نحوه ضبط درخواست‌ها و وضعیت کدهای پاسخ سرور (server status code) وجود دارد که می‌توانید بسته به نیاز و ترجیحات خود آنها را انتخاب نمایید.

Temporary Header and Token Replacement
در بخش Temporary header box، باید مقادیر token / cookies / header مربوط به کاربر عادی که می‌خواهید در درخواست واقعی جایگزین شوند، قرار دهید؛ به‌عنوان‌مثال، اگر برنامه‌ای از JWT token برای مکانیزم احراز هویت استفاده می‌کند، باید مقدار آن را در اینجا وارد کنید.

شما می‌توانید این مقدار احراز هویت (auth value) را به‌صورت دستی اضافه کنید یا از گزینه‌های زیر برای واکشی (fetch) آن از آخرین درخواست استفاده نمایید:

• اگر می‌خواهید مقدار Cookies header را از آخرین درخواست اضافه کنید → روی Fetch Cookies header کلیک کنید.
• اگر می‌خواهید مقدار Authorization header را اضافه کنید → روی Fetch Authorization header کلیک کنید.

به‌طور کلی، session cookies معمولاً زیر Cookies Header قرار می‌گیرند و auth token در Authorization Header قرار دارد.

راه‌اندازی Enforcement Detector
پس از بارگذاری session cookies، ضروری است که به Authorize مشخص کنید کدام درخواست‌ها باید intercept شوند و رفتار استاندارد برنامه هنگام مواجهه با درخواست‌های غیرمجاز یا دارای سطح دسترسی ناکافی چگونه تعریف شود.

برای شروع با Enforcement Detector، باید مشخصه‌ای از پاسخ برنامه را وارد کنید که بتوان آن را به‌عنوان نشانه‌ای از تلاش یک کاربر با سطح دسترسی محدود برای انجام عملی که مجوز کافی ندارد، پیش‌بینی کرد.
بر اساس تجربه من، استفاده از گزینه “Body (simple string): enforced message body contains” ساده‌ترین و درعین‌حال مؤثرترین روش برای پیکربندی است. نوع و محتوای مناسب با نیازهای خاص خود را انتخاب کنید و فراموش نکنید که روی دکمه “Add filter” کلیک نمایید.

استفاده از چندین فیلتر
همچنین لازم است بدانید که هنگام ارزیابی چندین فیلتر، مقایسه پیش‌فرض به‌صورت خودکار روی “And” تنظیم می‌شود. بنابراین، اگر برنامه پیام‌های خطای متفاوتی تولید می‌کند — مثلاً یک پیام برای تلاش جهت خواندن یک فایل و پیام دیگر برای تلاش جهت دسترسی به قابلیت‌های مدیریتی — باید برای هر سناریو یک فیلتر جداگانه ایجاد کرده و سپس مقایسه را از “And” به “Or” تغییر دهید.

پیکربندی Unauthenticated Detector
برای Unauthenticated Detector نیز همان رویه و مراحل مشابه را دنبال کنید.

فیلتر رهگیری (Interception Filter)
فیلتر Interception به‌صورت پیش‌فرض فقط درخواست‌هایی را رهگیری می‌کند که در محدوده تعریف‌شده (Scope items only) قرار دارند، بدون توجه به محتوای آنها. از میان این درخواست‌ها، به‌طور پیش‌فرض درخواست‌های مربوط به spider و همچنین URLهایی که شامل پسوندهای تصویری هستند، نادیده گرفته می‌شوند.
شما می‌توانید بسته به ترجیحات خود گزینه‌ها را انتخاب کرده و پس از تعیین type مناسب، روی دکمه “Add filter” کلیک کنید.

قابلیت Match/Replace
افزون بر این، Autorize دارای قابلیتی به نام Match/Replace است. از این ویژگی می‌توانید زمانی استفاده کنید که نیاز دارید یک هدر خاص یا یک پارامتر در بدنه درخواست (body parameter) را تغییر دهید.
برای مثال، اگر پارامتر ‘u.name’ در بدنه درخواست نیاز به جایگزین شدن با شناسه ادمین (مانند ‘a.name’) داشته باشد، می‌توانید Autorize را طوری پیکربندی کنید که این تغییر به‌صورت خودکار انجام شود.

در این بخش، شما می‌توانید از طریق افزودن مقادیر موردنظر، Autorize را برای انجام این جایگزینی‌ها تنظیم کنید.

سفارشی‌سازی فیلترها و مدیریت پاسخ‌ها

می‌توانید نوع درخواست‌هایی را که می‌خواهید مشاهده کنید از طریق نوار Table Filter انتخاب کنید.

• bypassed!: این endpoint ممکن است نسبت به IDOR آسیب‌پذیر باشد.
• Is enforced!: به‌نظر می‌رسد این endpoint محافظت‌شده است، اما نیاز به بررسی مجدد دارد.
• Enforcing!: این endpoint به‌صورت واضح در برابر IDOR محافظت می‌شود.

در نهایت، می‌توانید داده‌های فیلترشده را برای تحلیل‌های بیشتر از طریق تب Save/Restore ذخیره و صادر کنید.

نمایش عملی عملکرد Autorize

برای درک بهتر، یک نمایش سریع و عملی انجام می‌دهیم. در این تمرین، از یک PortSwigger lab از پیش‌راه‌اندازی‌شده با عنوان “Method-based access control can be circumvented” استفاده می‌کنیم. روی “access the lab” کلیک کرده و وارد برنامه شوید.

این آزمایش، یک آسیب‌پذیری Broken Access Control را نشان می‌دهد که در آن دو کاربر با نقش‌های متفاوت (سطح دسترسی بالا و پایین) وجود دارند. همین مفهوم را می‌توان برای کاربرانی با سطح دسترسی مشابه نیز به کار برد.

ابتدا باید کوکی‌های کاربر با سطح دسترسی پایین (کاربر عادی) را دریافت کنیم. در اینجا از اطلاعات کاربری پیش‌فرض برای کاربر عادی استفاده می‌کنیم:

Wiener:peter

سپس با ورود به برنامه، session cookie مربوط به این کاربر را استخراج می‌کنیم.

جزئیات بیشتری به‌روزرسانی شده‌اند:

ابتدا باید کوکی‌های مربوط به کاربر با سطح دسترسی پایین (کاربر عادی) را دریافت کنیم. در این سناریو، از اطلاعات کاربری پیش‌فرض زیر استفاده می‌کنیم:

Wiener : peter

پس از ورود به برنامه با این حساب، session cookie ایجادشده را برای استفاده در مراحل بعدی ذخیره می‌کنیم.

در درخواست ورود، session cookie مشابه نمونه زیر را مشاهده خواهید کرد. اکنون این cookie header را کپی کنید.

مقدار cookie header کپی‌شده را مطابق تصویر زیر در تب Autorize وارد کنید.

و گزینه Autorize را در حالت فعال نگه دارید.

برای بررسی امکان auth bypass، اکنون باید با کاربری با سطح دسترسی بالا (admin user) وارد شویم. دوباره به صفحه ورود مراجعه کرده و از اطلاعات کاربری زیر استفاده کنید:

Administrator : admin

پس از ورود موفق با حساب admin و مرور تمام URLهایی که مخصوص مدیر هستند، در تب Autorize چند درخواست برجسته‌شده را مشاهده خواهید کرد.

تفسیر نتایج و درک وضعیت‌های Authorization

• Authz. Status نشان می‌دهد که کدام endpoint‌ها برای کاربر wiener (کاربر عادی) قابل دسترسی هستند.
• Unauth. Status مربوط به کاربران غیرمجاز است؛ در این حالت، cookie و تمام authorization headers حذف می‌شوند. این ویژگی را می‌توان با غیرفعال‌کردن گزینه Check unauthenticated در تب تنظیمات Autorize غیرفعال کرد.

وضعیت‌های نمایش داده‌شده:

• قرمز [Bypassed!]: این endpoint ممکن است به مشکلات access control یا IDOR آسیب‌پذیر باشد.
• نارنجی [Is enforced!]: به‌نظر می‌رسد این endpoint محافظت‌شده است، اما با جایگزینی دستی مقدار cookie آن را مجدداً بررسی کنید.
• سبز [Enforced!]: این endpoint به‌طور واضح در برابر مشکلات access control یا IDOR محافظت می‌شود.

همان‌طور که در تصویر بالا مشاهده می‌شود، درخواست‌های شماره ۱، ۲، ۶ و ۷ دچار مشکل Broken Access Control هستند.

توجه داشته باشید که نتایج Autorize را به‌صورت کورکورانه دنبال نکنید. هایلایت قرمز به معنای آسیب‌پذیری یا عبور از کنترل دسترسی در همه endpointها نیست و ممکن است موارد مثبت کاذب وجود داشته باشد؛ بنابراین، حتماً بررسی‌های تکمیلی انجام دهید.

برخی سناریوهای ممکن دیگر:
فرض کنید در حال بررسی مشکلات احراز هویت بین دو کاربر با سطح دسترسی برابر هستید. در این حالت، ممکن است وضعیت Authz. Status مقدار Bypassed! و وضعیت Unauth. Status مقدار Enforced! را نشان دهد. این بدان معناست که درخواستی وجود دارد که آن endpoint برای کاربر دوم قابل دسترسی است، اما احراز هویت برای کاربران غیرمجاز به درستی پیاده‌سازی شده است.

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

نتیجه‌گیری

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