Privilege Escalation — ارتقای سطح دسترسی

ارتقای سطح دسترسی چیست؟

ارتقای سطح دسترسی (Privilege Escalation) یعنی یک اصیل — کاربر، سرویس یا توکن — به قابلیت یا داده‌ای دست پیدا می‌کند که سیاست دسترسی سازمان آن را برایش تعریف نکرده است. در ادبیات امنیت شبکه این اصطلاح معمولاً به‌معنای رسیدن به root یا SYSTEM روی یک میزبان است، اما در برنامه‌های وب موضوع در لایه‌ی برنامه اتفاق می‌افتد و اغلب هیچ ارتباطی به سیستم‌عامل ندارد.

دو محور اصلی:

• ارتقای عمودی (Vertical): عبور از مرز نقش‌ها. کاربر عادی به قابلیت مدیر یا اپراتور می‌رسد — تغییر نقش خودش، دسترسی به پنل مدیریت، اجرای عملیات مالی، مشاهده‌ی داده‌ی همه‌ی مستأجرها.
• ارتقای افقی (Horizontal): ماندن در همان سطح نقش اما رسیدن به دارایی کاربر دیگر. این همان چیزی است که در قالب IDOR گزارش می‌شود. اگر کاربر مقصد یک مدیر باشد، ارتقای افقی عملاً به عمودی تبدیل می‌شود — و این زنجیره‌ی رایجی است.

هر دو محور زیرمجموعه‌ی کنترل دسترسی شکسته (A01:2025) هستند. در راهنمای آزمون OWASP هم «آزمون ارتقای سطح دسترسی» یکی از چهار آزمون بخش مجوزدهی (WSTG-ATHZ) است.

مسیرهای رایج ارتقای دسترسی در وب

• Mass Assignment روی فیلد نقش. برنامه بدنه‌ی JSON را مستقیماً به موجودیت کاربر نگاشت می‌کند و {"role":"admin"} یا {"isAdmin":true} پذیرفته می‌شود. رایج‌ترین مسیر ارتقای عمودی در APIهای مدرن.
• اعتماد به ادعای داخل توکن. نقش کاربر داخل JWT ذخیره شده و سرور بدون راستی‌آزمایی درست امضا به آن اعتماد می‌کند. با حملات alg: none یا سردرگمی کلید، مهاجم نقش خودش را بازنویسی می‌کند.
• مرور اجباری به اندپوینت‌های مدیریتی. مسیر /admin/* فقط از منو حذف شده و در سمت سرور بررسی نقش ندارد. نسخه‌های قدیمی API که پس از انتشار نسخه‌ی جدید بدون کنترل باقی می‌مانند، همین وضعیت را دارند.
• دور زدن ACL لبه. اگر بررسی نقش در پروکسی جلویی و بر پایه‌ی مسیر انجام شود، هدرهایی مثل X-Original-URL و X-HTTP-Method-Override یا اختلاف نرمال‌سازی مسیر بین پروکسی و اپلیکیشن، آن را دور می‌زنند.
• رد کردن مرحله در فرایند چندمرحله‌ای. رسیدن مستقیم به مرحله‌ی نهایی یک فرایند تأیید — مثلاً «فعال‌سازی حساب» یا «تأیید سطح دسترسی» — بدون گذر از مرحله‌ی بازبینی.
• سوءاستفاده از قابلیت‌های پشتیبانی. قابلیت «ورود به‌جای کاربر» (Impersonation) که برای پشتیبانی ساخته شده و کنترل دسترسی کافی ندارد، مسیر مستقیمی به هر حسابی است.
• ارتقا از راه دعوت و مدیریت تیم. در برنامه‌های چندمستأجری، اندپوینت دعوت عضو جدید اغلب اجازه می‌دهد نقش دعوت‌شونده تعیین شود بدون اینکه بررسی شود دعوت‌کننده حق اعطای آن نقش را دارد.
• ارتقا از راه بازیابی رمز. اگر جریان بازیابی رمز عبور اجازه دهد آدرس ایمیل هدف تعیین شود یا توکن بازیابی قابل پیش‌بینی باشد، تصاحب حساب مدیر ممکن می‌شود.

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

یک سامانه‌ی SaaS چندمستأجری با نقش‌های member، owner و support. رابط کاربری برای نقش member هیچ راهی برای تغییر نقش نشان نمی‌دهد.

در تست، اندپوینت POST /api/orgs/{org}/invites بررسی می‌شود. سرور تأیید می‌کند که دعوت‌کننده عضو همان سازمان است — اما بررسی نمی‌کند که آیا او حق اعطای نقش owner را دارد. یک کاربر member می‌تواند آدرس ایمیل دومی از خودش را با نقش owner دعوت کند و در عرض یک دقیقه مالک سازمان شود.

در همان تست، یافته‌ی دوم روی PATCH /api/users/me پیدا می‌شود: فیلد orgId در بدنه پذیرفته می‌شود و کاربر می‌تواند خودش را به سازمان دیگری منتقل کند — یعنی مرز جداسازی مستأجرها هم شکسته است. هیچ‌کدام از این دو با اسکنر خودکار پیدا نمی‌شد، چون هر دو درخواست از نظر نحوی کاملاً معتبرند.

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

1. ماتریس نقش در برابر قابلیت بسازید. پیش از هر آزمونی مشخص کنید هر نقش باید چه کاری بتواند بکند. بدون این ماتریس، تشخیص «ارتقا» ممکن نیست — و همین دلیل ناتوانی ابزارهای خودکار است.
2. حساب هر نقش را بگیرید و با هر کدام کل برنامه را پیمایش کنید تا نقشه‌ی کامل درخواست‌ها ساخته شود.
3. بازپخش رو به بالا: درخواست‌های نقش بالا را با نشست نقش پایین بفرستید. افزونه‌های خانواده‌ی Autorize در Burp Suite این مقایسه را خودکار می‌کنند.
4. فیلدهای پنهان را تزریق کنید: role، isAdmin، permissions، orgId، tenantId، status را به بدنه‌ی درخواست اضافه کنید — حتی اگر در پاسخ سرور دیده نشوند.
5. توکن را بیازمایید: اگر نقش داخل توکن است، همه‌ی آزمون‌های JWT اجرا شوند.
6. مسیرهای مدیریتی را کشف کنید: با ffuf و فهرست‌های واژگان تخصصی، به‌علاوه‌ی استخراج مسیرها از باندل جاوااسکریپت و فایل‌های .map.
7. فرایندهای چندمرحله‌ای را از وسط شروع کنید و ببینید آیا وضعیت مرحله‌ی قبل راستی‌آزمایی می‌شود.

ارتقای دسترسی در سطح سیستم‌عامل — به‌اختصار

وقتی یک آسیب‌پذیری وب به اجرای کد از راه دور ختم شود، تستر معمولاً با کمترین سطح دسترسی روی سرور قرار می‌گیرد — کاربر سرویس وب مثل www-data یا حساب Application Pool. در این نقطه، ارتقای دسترسی سیستمی موضوعی برای مرحله‌ی پساسوءاستفاده است و مسیرهای متعارفش شامل پیکربندی نادرست sudo، مجوزهای نادرست فایل‌ها و سرویس‌ها، باینری‌های SUID و هسته‌ی وصله‌نشده است.

دو نکته‌ی مهم برای دامنه‌ی کاری تست نفوذ وب:

• این مرحله باید صراحتاً در قرارداد و دامنه‌ی کار (Scope) مجاز شده باشد. اثبات RCE با یک دستور بی‌خطر معمولاً کافی است و ادامه‌ی مسیر تا root روی سرور عملیاتی، بدون توافق کتبی انجام نمی‌شود.
• از منظر اثر، ارزش گزارش در نشان دادن مرز شکسته‌شده است، نه در حداکثرسازی دسترسی. اثبات اینکه از برنامه می‌توان به شبکه‌ی داخلی یا داده‌ی سایر مستأجرها رسید، برای تصمیم‌گیری مدیریتی کافی است. حرکت جانبی و ادامه‌ی زنجیره موضوع حرکت جانبی است.

تمرکز این صفحه و تمرکز کاری ما، لایه‌ی برنامه است — جایی که بیشترین یافته‌های واقعی در پروژه‌های تست نفوذ از آن بیرون می‌آید.

نمونه‌ی فنی و نگاشت به استانداردها

شکل معمول یافته‌ی ارتقای عمودی در گزارش:

POST /api/orgs/42/invites HTTP/1.1
Cookie: session=<member-role-session>
Content-Type: application/json

{"email":"tester+2@example.com","role":"owner"}

HTTP/1.1 201 Created

نگاشت به استانداردها

• OWASP Top 10:2025: A01 — Broken Access Control.
• CWE-269 (مدیریت نادرست امتیاز) و CWE-266 (اعطای نادرست امتیاز) شناسه‌های اصلی؛ CWE-863 (مجوزدهی نادرست) و CWE-862 (نبود مجوزدهی) برای حالت‌های مرتبط. CWE-269 در سیاهه‌ی CWEهای دسته‌ی A06:2025 (طراحی ناامن) هم فهرست شده است، که نشان می‌دهد بخشی از این نقص‌ها ریشه‌ی طراحی دارند نه پیاده‌سازی.
• WSTG-ATHZ: آزمون ارتقای سطح دسترسی، یکی از چهار آزمون بخش مجوزدهی.

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