بررسی Bypassing Authorization Schema
در این بخش از دوره آموزشی OWASP-WSTG به پنجمین بخش از استاندارد WSTG با شناسه WSTG-ATHZ-02 می پردازیم که مربوط به بررسی Bypassing Authorization Schema می باشد.
خلاصه
آزمون Bypassing Authorization Schema بر بررسی این موضوع تمرکز دارد که چگونه Authorization Schema برای هر نقش یا privilege برای دستیابی به توابع و منابع رزرو شده پیاده سازی شده‌است.
برای هر عملکرد و درخواستی که برنامه در طول مرحله پس از احراز هویت اجرا می‌کند، تست نفوذگر می‌بایست موارد زیر را برررسی و تایید کند:
• آیا امکان دسترسی به آن منبع وجود دارد حتی اگر کاربر Authenticate نشده باشد؟
• آیا دسترسی به این منبع پس از خروج از سیستم ممکن است؟
• آیا دسترسی به کارکردها و منابعی که باید برای کاربری که نقش یا امتیاز متفاوتی دارد، در دسترس باشد، امکان پذیر است؟
سعی کنید به برنامه به عنوان یک Administrative User دسترسی داشته باشید و تمام کارکردهای مدیریتی را دنبال کنید.
• آیا دسترسی به توابع اجرایی در صورتی که تست نفوذگر به عنوان یک کاربر غیر مدیریتی وارد سیستم شود، امکان پذیر است؟
• آیا می‌توان از این عملکردهای مدیریتی به عنوان یک کاربر با نقش متفاوت استفاده کرد و این اقدام را برای چه کسی باید رد یا غیرفعال کرد؟
اهداف تست
دسترسی‌هایی که به صورت افقی یا عمودی تعریف می‌شوند را بررسی کنید.
چگونه تست را انجام دهیم
• دسترسی به منابع و اجرای عملیات به صورت افقی.
• دسترسی به منابع و اجرای عملیات به صورت عمودی.
تست Horizontal Bypassing Authorization Schema
برای هر کارکرد، نقش خاص، یا درخواست اجرای برنامه، بررسی موارد زیر ضروری است:
• آیا دسترسی به منابعی که باید برای کاربری که دارای هویت متفاوتی با همان نقش یا امتیاز است، در دسترس باشد، امکان پذیر است؟
• آیا این امکان وجود دارد که توابعی را بر روی منابعی که باید برای کاربری که دارای هویت متفاوتی است در دسترس باشد، اجرا کنیم؟
لازم به ذکر است که برای انجام فرآیند تست در این بخش نیاز به دو کاربر با سطح دسترسی یکسان برای هر نقش می‌باشد:
- ثبت یا تولید دو کاربر با امتیازات یکسان.
- ایجاد و فعال نگه داشتن دو جلسه مختلف (یکی برای هر کاربر).
- برای هر درخواست، پارامترهای مربوطه و شناسه جلسه را از توکن یک به توکن دو تغییر داده و پاسخ‌ها را برای هر توکن بررسی کنید.
- یک برنامه در صورتی آسیب‌پذیر در نظر گرفته خواهد شد که پاسخ‌ها یکسان باشند، حاوی داده‌های خصوصی یکسان باشند یا عملیات موفق بر روی منابع یا داده‌های دیگر کاربران را نشان دهند.
به عنوان مثال، فرض کنید که تابع viewSettings بخشی از هر منوی برنامه کاربردی با همان نقش است و دسترسی به آن با درخواست URL زیر امکان پذیر است:
www.example.com/account/viewSettings
سپس، درخواست HTTP زیر هنگام فراخوانی تابع viewSettings ایجاد می‌شود:
پاسخ معتبر و مشروع:
مهاجم ممکن است درخواست‌ها را با همان پارامتر username امتحان و اجرا کند:
اگر پاسخ مهاجم شامل داده‌های example_user باشد، آنگاه برنامه برای حملات Lateral Movement آسیب‌پذیر است، که در آن کاربر می‌تواند داده‌های کاربر دیگر را بخواند یا آن را بازنویسی کند.
تست Vertical Bypassing Authorization Schema
یک vertical authorization bypass مخصوص موردی است که مهاجم نقشی بالاتر از نقش خود به دست می‌آورد. آزمایش برای این مدل Bypass بر بررسی این موضوع تمرکز دارد که چگونه vertical authorization schema برای هر نقش اجرا شده‌است. برای هر تابع، صفحه، نقش خاص یا درخواستی که برنامه اجرا می‌کند، لازم است تا موارد زیر بررسی شود:
• منابع دسترسی که باید تنها برای یک کاربر نقش بالاتر در دسترس باشند.
• عملیات توابع بر روی منابعی که تنها باید توسط یک کاربر که دارای هویت نقش خاص یا بالاتر است، اجرا شود.
موار زیر برای هر نقش نیاز است:
- یک کاربر را ثبت‌نام کنید.
- ایجاد و حفظ دو جلسه مختلف براساس دو نقش متفاوت.
- برای هر درخواست، شناسه جلسه را از شناسه جلسه اصلی به شناسه جلسه نقش دیگر تغییر داده و پاسخ‌ها را برای هر یک ارزیابی کنید.
- یک برنامه در صورتی آسیب‌پذیر در نظر گرفته خواهد شد که جلسه دارای امتیاز ضعیف‌تر، داده‌های مشابه را شامل شود یا بیانگر عملیات موفقیت‌آمیز بر روی کارکردهای با امتیاز بالاتر است.
Banking Site Roles Scenario
جدول زیر نقش‌های سیستمی در یک سایت بانکی را نشان می‌دهد. هر نقش به مجوزهای خاص برای عملکرد منوی رویداد متصل می‌شود:
این برنامه در صورتی آسیب‌پذیر در نظر گرفته خواهد شد که:
• Customerبتواند وظایف و توابع مربوط به administrator، manager یا staff را اجرا کند؛
• کاربر Staff بتواند وظایف و توابع administrator یا manager را اجرا کند؛
• Manager بتواند وظایف و توابع administrator را اجرا کند.
فرض کنید که تابع deleteEvent بخشی از منوی حساب administrator برنامه است و دسترسی به آن با درخواست URL زیر امکان پذیر است:
www.example.com/account/deleteEvent
سپس، درخواست HTTP زیر هنگام فراخوانی تابع deleteEvent ایجاد می‌شود:
پاسخ معتبر:
مهاجم ممکن است همان درخواست را امتحان و اجرا کند:
اگر پاسخ درخواست مهاجم شامل همان داده {“message”: “Event was deleted”} باشد، برنامه آسیب‌پذیر است.
Administrator Page Access
فرض کنید که منوی administrator در حساب کاربری مدیر برنامه در دسترس است.
برنامه در صورتی آسیب‌پذیر در نظر گرفته خواهد شد که هر نقشی به جز administrator بتواند به منوی مدیر دسترسی داشته باشد. گاهی اوقات، توسعه دهندگان، authorization validation را تنها در سطح GUI انجام می‌دهند و توابع را بدون اعتبارسنجی صحیح در تمام ساختار برنامه رها می‌کنند، در نتیجه این موضوعات به طور بالقوه منجر به آسیب‌پذیری می‌شوند.
تست Access to Administrative Functions
برای مثال، فرض کنید که تابع addUser بخشی از منوی مدیریتی برنامه است و امکان دسترسی به آن با درخواست URL زیر وجود دارد.
www.example.com/admin/addUser
سپس، درخواست HTTP زیر هنگام فراخوانی تابع addUser ایجاد می‌شود:
سوالات یا ملاحظات زیر باید در نظر گرفته شود:
• چه اتفاقی می‌افتد اگر یک کاربر غیر مدیر تلاش کند این درخواست را اجرا کند؟
• آیا کاربر ایجاد خواهد شد؟
• اگر چنین است، آیا کاربر جدید می‌تواند از امتیازات خود استفاده کند؟
تست Access to Resources Assigned to a Different Role
برنامه‌های کاربردی مختلف کنترل منابع را براساس نقش‌های کاربر ایجاد می‌کنند. بیایید یک مثال از رزومهها یا CV های(curriculum vitae) آپلود شده در یک فرم شغلی برای یک S3 bucket در نظر بگیریم.
به عنوان یک کاربر عادی، دسترسی به مکان آن فایل‌ها را امتحان کنید. اگر می‌توانید آن‌ها را بازیابی کنید، آن‌ها را اصلاح کنید یا آن‌ها را حذف کنید، برنامه آسیب‌پذیر است.
تست Special Request Header Handling
برخی از برنامه‌ها هدرهای غیر استانداردی مانند X-Original-URL یا X-Rewrite-URL را به منظور Override نمودنURL هدف در درخواست‌ها با آنچه که در مقدار هدر مشخص شده‌است، پشتیبانی می‌کنند.
این رفتار می‌تواند در شرایطی که برنامه کاربردی پشت مولفه‌ای است که محدودیت کنترل دسترسی را براساس URL درخواست اعمال می‌کند، مورد استفاده قرار گیرد.
نوع محدودیت کنترل دسترسی براساس URL درخواست شده می‌تواند، برای مثال، مسدود کردن دسترسی از اینترنت به یک بخش مدیریتی مثل /console یا /admin باشد.
برای تشخیص پشتیبانی برای هدرهای مذکور، مراحل زیر را می‌توان اعمال کرد.
اگر پاسخ هر یک از این درخواست‌ها شامل شاخص‌هایی باشد که منبع پیدا نشده است، این امر نشان می‌دهد که برنامه از هدرهای درخواست خاص پشتیبانی می‌کند. این نشانگرها ممکن است شامل کد وضعیت پاسخ HTTP ۴۰۴، یا پیام ” resource not found” در بدنه پاسخ باشند.
هنگامی که پشتیبانی برای هدر X-Original-URL یا X-Rewrite-URL تایید شد، آنگاه تست Bypass در برابر محدودیت کنترل دسترسی می‌تواند با ارسال درخواست مورد انتظار به برنامه تحت نفوذ قرار گیرد اما تعیین یک آدرس “مجاز” توسط front-end به عنوان آدرس درخواست اصلی و مشخص کردن آدرس هدف واقعی در هدرX-Original-URL یا X-Rewrite-URL وابسته به یک آدرس پشتیبانی شده است. اگر هر دو پشتیبانی شدند، یکی پس از دیگری را امتحان کنید تا بررسی کنید که Bypass برای کدام هدر موثر است.
۴. Other Headers to Consider
اغلب، پنل‌های مدیریتی یا بخش‌های مربوط به وظایف مدیریتی، تنها برای کلاینت‌ها در شبکه‌های محلی در دسترس هستند، بنابراین ممکن است بتوان از پروکسی‌های مختلف و یا هدرهای HTTP مرتبط برای دسترسی استفاده کرد. برخی از هدرها و مقادیر مورد آزمایش عبارتند از:
نکته: اضافه کردن یک عنصر پورت به همراه آدرس یا نام میزبان نیز ممکن است به Bypass نمودن edge protections ها مانند فایروال برنامه‌های کاربردی وب و غیره کمک کند. برای مثال:
127.0.0.4:80
127.0.0.4:443
127.0.0.4:43982
Remediation
استفاده از اصل حداقل امتیاز در کاربران، نقش‌ها و منابع برای اطمینان از این که هیچ دسترسی غیر مجاز رخ نمی‌دهد، در این بخش مناسب می‌باشد. همچنین تعیین صحیح نقش‌ها و دسترسی‌ها موضوع دیگری است که باید به آن توجه شود.
ابزارها
OWASP Zed Attack Proxy (ZAP)
ZAP add-on: Access Control Testing
Port Swigger Burp Suite
Burp extension: AuthMatrix
Burp extension: Autorize
