Broken Access Control — کنترل دسترسی شکسته

کنترل دسترسی شکسته چیست؟

کنترل دسترسی (Access Control) سازوکاری است که تعیین می‌کند هر کاربر — چه احراز هویت شده باشد چه نشده — مجاز به دیدن، تغییر یا حذف کدام داده و اجرای کدام عملیات است. «شکسته بودن» این کنترل به‌ندرت به‌معنای نبودِ کامل سیاست است؛ تقریباً همیشه یعنی سیاست وجود دارد اما در نقطه‌ی درست اعمال نمی‌شود.

برای فهم مکانیزم، به سه نقطه‌ای فکر کنید که یک برنامه‌ی وب معمول می‌تواند تصمیم مجوزدهی بگیرد:

• رابط کاربری: دکمه‌ی «حذف» برای کاربر عادی رندر نمی‌شود.
• لایه‌ی مسیریابی یا Gateway: نقش user اجازه‌ی رسیدن به مسیر /admin/* را ندارد.
• لایه‌ی دسترسی به داده: این رکورد مشخص، متعلق به همین کاربر است یا نه.

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

OWASP در داده‌ی نسخه‌ی ۲۰۲۵ آماری منتشر کرده که ارزش نقل‌کردن دارد: ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند. این عدد به‌معنای «همه‌ی برنامه‌ها بحرانی‌اند» نیست، اما به‌روشنی می‌گوید این دسته را نمی‌توان با فرض «ما مرتب هستیم» رد کرد.

انواع نقص کنترل دسترسی

سه محور اصلی برای دسته‌بندی وجود دارد:

و الگوهای اجرایی که این سه محور از دل آن‌ها بیرون می‌آیند:

• مرور اجباری (Forced Browsing): باز کردن مستقیم مسیری که هیچ لینکی به آن وجود ندارد — /admin/getAppInfo، /reports/export، نسخه‌های قدیمی API مثل /api/v1/ که پس از انتشار v2 بدون کنترل باقی مانده‌اند. «لینک‌نشده بودن» یک کنترل امنیتی نیست.
• دستکاری پارامتر (Parameter Tampering): تغییر شناسه در مسیر، Query String، بدنه‌ی JSON، کوکی یا حتی ادعای داخل توکن JWT. حالت خاص و پرتکرار آن IDOR است.
• اتکا به کنترل سمت کلاینت: دکمه پنهان است، فیلد disabled است، یا مسیر در روتر جاوااسکریپتی محافظت شده — اما همان درخواست با یک ابزار خط فرمان بدون هیچ مانعی اجرا می‌شود.
• ناهماهنگی متدها و مسیرهای موازی: بررسی مجوز روی GET هست ولی روی PUT/DELETE نیست؛ یا روی صفحه‌ی HTML هست ولی روی اندپوینت JSON معادلش نیست.
• دور زدن ACL لبه: هدرهایی مثل X-Original-URL و X-HTTP-Method-Override، یا اختلاف نرمال‌سازی مسیر بین پروکسی جلویی و اپلیکیشن پشتی.

چه چیزی در نسخه‌ی ۲۰۲۵ تغییر کرد

در OWASP Top 10:2025 این دسته با ۴۰ CWE بزرگ‌ترین دسته‌ی فهرست است و دو تغییر ساختاری مهم دارد. صفحه‌ی رسمی A01:2025 تصریح می‌کند که SSRF (یعنی CWE-918) — که در نسخه‌ی ۲۰۲۱ دسته‌ی مستقل A10 بود — در این دسته ادغام شده، و CSRF (یعنی CWE-352) هم اینجا قرار دارد.

منطق ادغام قابل دفاع است: در SSRF مهاجم سرور را وادار می‌کند از طرف او به منبعی برسد که حق دسترسی به آن را ندارد، و در CSRF مرورگر قربانی وادار می‌شود عملیاتی را با مجوز قربانی اجرا کند. هر دو در ماهیت، شکست در اعمال مرز اعتماد هستند.

CWEهای شاخص این دسته: CWE-862 (نبود مجوزدهی)، CWE-285 (مجوزدهی نادرست)، CWE-200 و CWE-201 (افشای اطلاعات حساس)، به‌علاوه‌ی CWE-918 و CWE-352. در فهرست ۲۰۲۵ CWE Top 25 هم CWE-352 رتبه‌ی سوم و CWE-862 رتبه‌ی چهارم را دارند.

سناریوی واقعی

یک سامانه‌ی فروش سازمانی با سه نقش: agent، manager و admin. پنل مدیریت با یک روتر سمت کلاینت ساخته شده و برای نقش agent هیچ آیتم منویی از بخش «گزارش‌ها» رندر نمی‌شود. تیم توسعه این را کنترل دسترسی می‌داند.

در تست نفوذ، فایل‌های جاوااسکریپت بسته‌بندی‌شده بررسی می‌شوند. داخل باندل، تعریف مسیرها و آدرس اندپوینت‌های API آن‌ها به‌طور کامل موجود است — از جمله /api/reports/export?scope=all. ارسال همان درخواست با نشست نقش agent پاسخ 200 و خروجی کامل گزارش فروش همه‌ی شعب را برمی‌گرداند. بررسی نقش فقط در رندر منو بوده، نه در کنترلر.

یافته‌ی دوم روی PATCH /api/users/{id} است: بررسی مالکیت وجود دارد و کاربر فقط پروفایل خودش را تغییر می‌دهد، اما بدنه‌ی درخواست مستقیماً به شیء کاربر نگاشت می‌شود و افزودن فیلد "role":"admin" پذیرفته می‌شود — الگوی Mass Assignment: مالکیت کنترل شده، اما ویژگی‌های قابل نوشتن محدود نشده‌اند. هیچ‌کدام از این دو با اسکنر خودکار کشف نمی‌شد، چون ابزار نمی‌داند نقش agent باید به چه چیزی دسترسی داشته باشد.

چگونه در تست نفوذ کشف می‌شود

روش استاندارد، آزمون تفاضلی با چند حساب است. مراحل عملی:

1. نگاشت نقش‌ها: برای هر نقش حداقل یک حساب بگیرید، و برای آزمون افقی دو حساب هم‌سطح. بدون حساب دوم، آزمون افقی عملاً ممکن نیست.
2. ساخت نقشه‌ی کامل درخواست‌ها: با هر حساب کل برنامه را پیمایش کنید. باندل‌های جاوااسکریپت، فایل‌های .map و مستندات OpenAPI را برای اندپوینت‌های نامرئی در رابط کاربری بررسی کنید؛ ffuf برای کشف مسیرهای لینک‌نشده و نسخه‌های قدیمی API مفید است.
3. بازپخش متقاطع: هر درخواست نقش بالا را با نشست نقش پایین دوباره بفرستید و برعکس. افزونه‌های خانواده‌ی Autorize در Burp Suite و امکانات مشابه در Caido این مقایسه را خودکار می‌کنند، اما تفسیر نتیجه دستی است.
4. آزمون متدها و ویژگی‌ها: اگر GET محافظت شده، همان منبع را با PUT، DELETE و هدرهای Method Override بیازمایید؛ و فیلدهای اضافی مثل role یا tenantId را به بدنه‌ی درخواست اضافه کنید.

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

نمونه‌ی فنی

شکل تفاضلی یافته در گزارش، معمولاً همین است — دو درخواست یکسان با دو نشست متفاوت:

GET /api/v1/invoices/1042 HTTP/1.1
Host: app.example.com
Cookie: session=<session-of-user-A>

HTTP/1.1 200 OK
{"id":1042,"owner":"user-B","total":48900000}

پاسخ باید 403 Forbidden می‌بود. نکته‌ی مهم در گزارش‌نویسی این است که شواهد باید مالکیت رکورد را نشان دهد، نه صرفاً کد وضعیت ۲۰۰ — یعنی باید ثابت شود رکورد ۱۰۴۲ واقعاً متعلق به کاربر دیگری است. برای الگوی Mass Assignment هم شکل ساده‌ی اثبات مفهوم این است:

PATCH /api/users/501 HTTP/1.1
Content-Type: application/json

{"displayName":"test","role":"admin"}

اشتباهات رایج

دو اشتباه پرتکرار دیگر:

• «مسیرش لینک نشده، پس امن است.» مسیرهای لینک‌نشده از باندل جاوااسکریپت، فایل‌های .map، آرشیوهای اینترنتی، مخازن گیت و پیام‌های خطا بیرون می‌آیند. این «امنیت از راه ابهام» است، نه کنترل دسترسی.
• «بررسی در Middleware است، پس همه‌جا اعمال می‌شود.» فقط وقتی درست است که هیچ مسیری از Middleware عبور نکند و بررسی در سطح رکورد هم انجام شود. اندپوینت‌های داخلی، Webhookها و نسخه‌های قدیمی API معمولاً از این زنجیره خارج‌اند.

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