WSTG-IDNT-01

بررسی Role Definitions

در این بخش از دوره آموزشی OWASP-WSTG به دومین بخش از استاندارد WSTG با شناسه WSTG-IDNT-01 می پردازیم که مربوط به بررسی Role Definitions می باشد.

خلاصه

اپلیکیشن‌ها انواع مختلفی از کارکردها و خدمات را ارائه می‌دهند که هر کدام به مجوزهای دسترسی براساس نیازهای کاربر نیاز دارند که این کاربر می‌تواند:

• یک مدیر باشد که عملکردهای برنامه را مدیریت می‌کنند.
• یک Auditor باشد که به بررسی تراکنش‌های اپلیکیشن پرداخته و گزارشی مفصل ارائه می‌دهد.
• یک مهندس پشتیبانی باشد که به مشتریان کمک می‌کند تا اشکال زدایی کنند و مسائل مربوط به حساب‌هایشان را حل نمایند.
• یک مشتری باشد که با اپلیکیشن ارتباط برقرار می‌کند و از خدمات آن بهره‌مند می‌شود.

آشنایی با WSTG-CONFIG-11

به منظور کنترل این کاربردها و هر مورد استفاده دیگر برای آن برنامه، تعاریف مربوط به هر نقش تنظیم می‌شوند (معمولا به عنوان Role-based access control یا RBAC شناخته می‌شوند). براساس این نقش‌ها، کاربر قادر به انجام فعالیت مورد نیاز خود خواهد بود.

اهداف تست

• شناسایی و مستندسازی نقش‌های مورد استفاده برنامه
• تلاش برای جابجایی، تغییر یا دسترسی به نقش‌های دیگر
• بررسی جزییات نقش‌ها و لزوم اعمال مجوزهای داده‌شده

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

شناسایی نقش‌ها

تست نفوذگر باید شناسایی نقش‌های برنامه مورد آزمایش را از طریق هر یک از روش‌های زیر انجام دهد:

• مستندات برنامه
• راهنمایی توسط توسعه دهندگان یا مدیران برنامه کاربردی
• توضیحات (Comments) اپلیکیشین
• فاز نمودن نقش های احتمالی بوسیله:
1- متغیر کوکی (role=admin, isAdmin=True)
2- متغیر حساب کاربری (Role: manager)
3- دایرکتوری ها و فایل های پنهان (/admin, /mod, /backups)
4- سوییچ به کاربران شناخته شده (admin, backups و غیره)

جابجایی به نقش‌های موجود

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

بررسی Roles Permissions

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

یک مهندس پشتیبانی نباید قادر به انجام ویژگی‌های مدیریتی، مدیریت Backupها یا انجام هر گونه تراکنش به جای یک کاربر باشد.

یک مدیر یا Administrator نباید قدرت کامل بر روی سیستم را داشته باشد. عملکرد حساس مدیریت باید از MFA یا Multi Factor Authentication برای اطمینان از این که واقعا مدیر تراکنش را انجام می‌دهد استفاده کند.

یک مثال واضح در این مورد حادثه توئیتر در سال ۲۰۲۰ بود:

blog.twitter.com/en_us/topics/company/2020/an-update-on-our-security-incident.html

ابزارها

تست‌های ذکر شده در بالا را می‌توان بدون استفاده از هر ابزاری به جز ابزاری که برای دسترسی به سیستم استفاده می‌شود، انجام داد.
برای آسان‌تر کردن و مستندسازی بیشتر موارد، می‌توانید از ابزارهای زیر استفاده کنید:

• Burp’s Autorize extension
• ZAP’s Access Control Testing add-on