api1.md

نقض مجوزدهی در سطح اشیاء

---

ضعف امنیتی	عوامل تهدید / مسیر حمله	پیامد
خاص API / قابلیت بهره‌برداری: آسان	میزان شیوع: گسترده/ قابلیت تشخیص: متوسط	پیامد فنی: شدید / خاص کسب و کار
مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء1 ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند.	این حمله رایج ترین ‌آسیب‌پذیری APIها بوده و بیشترین پیامدها را نیز در پی دارد. مکانیزم‌های مجوزدهی و کنترل دسترسی در اپلیکیشن‌های مدرن، پیچیده و گسترده هستند. حتی اگر اپلیکیشن زیرساخت مناسب را برای کنترل‌های مجوزدهی ‌‌‌‌پیاده‌سازی نماید، ممکن است توسعه دهندگان پیش از دسترسی به اشیا حساس، استفاده از این کنترل‌ها را فراموش نمایند. تشخیص نقایص مربوط به کنترل دسترسی از طریق تست‌های ایستا یا پویا به صورت خودکار غالبا امکان پذیر نیست.	دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد.

مهاجمین می‌توانند از نقاط و توابع ‌آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره‌برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم‌گیری درباره دسترسی کلاینت به اشیا از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارد.

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

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

آیا API از نظر نقض مجوزدهی در سطح اشیاء ² آسیب‌پذیر است؟

---

مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد ‌‌‌‌پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید. هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده³ به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند. وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد. در مسئله‌ی Broken Object Level Authorization (BOLA)، امنیت کاربران در دسترسی به اطلاعات و منابع در سیستم به خطر می‌افتد. این مشکل زمانی رخ می‌دهد که سیستم یک درخواست API حاوی یک شناسه (مثلاً شناسه یک مورد یا اشیاء خاص) را دریافت می‌کند و بدون بررسی دقیق این شناسه و اعتبارسنجی آن، به منابع مرتبط با آن شناسه دسترسی می‌دهد. مهاجمان با تغییر شناسه در درخواست‌های خود می‌توانند به اطلاعاتی دسترسی پیدا کنند که به طور عادی نباید به آن‌ها دسترسی داشته باشند. در مورد Broken Function Level Authorization (BFLA)، مشکل بیشتر در اجازه دسترسی به عملکردها یا نقطه آسیب‌پذیر API وابسته به توابع است. به عبارت دیگر، مهاجمان در اینجا به دسترسی به توابع سیستم یا نقطه‌های آسیب‌پذیر API که اصولاً نباید به آنها دسترسی داشته باشند، دست پیدا می‌کنند. این مشکل معمولاً بدون در نظر گرفتن شیء‌های خاص و فقط با تغییر درخواست‌ها برای توابع خاص رخ می‌دهد و منجر به اعتبارسنجی نادرست انجام می‌شود.

مثال‌هایی از سناریوهای حمله

---

سناریو #1

یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذکور را دارند و الگوی آنها به صورت /shops/{shopName}/revenue_data.json می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن {shopName} در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد.

سناریو #2

یک تولیدکننده خودرو از طریق یک واسط برنامه‌نویسی (API) امکان کنترل از راه دور خودروها را برای ارتباط با تلفن همراه راننده فراهم کرده است. این API به راننده این امکان را می‌دهد که موتور خودرو را از راه دور روشن و خاموش کند و درب‌ها را قفل و باز کند. در این فرآیند، کاربر شماره شناسایی خودرو (VIN) را به API ارسال می‌کند. متأسفانه، API قادر به اعتبارسنجی نمی‌باشد که آیا VIN به ماشینی کاربر وارد شده اختصاص دارد یا نه. این مشکل منجر به وقوع یک آسیب‌پذیری به نام BOLA (Bypass of Logical Access) می‌شود. به این ترتیب، مهاجم می‌تواند به خودروهایی دسترسی پیدا کند که به او تعلق ندارند و به آن‌ها دسترسی پیدا کند.

سناریو #3

یک سرویس ذخیره‌سازی اسناد آنلاین به کاربران این امکان را می‌دهد که اسناد خود را مشاهده، ویرایش، ذخیره و حذف کنند. هنگامی که کاربری یکی از اسناد خود را حذف می‌کند، یک عملیات درخواستی به نام GraphQL Mutation با استفاده از شناسه (ID) مربوط به سند حذف‌شده به API ارسال می‌شود. این درخواست GraphQL به API اطلاع می‌دهد که یک سند باید حذف شود و API مسئول انجام این عملیات حذف است.

POST /graphql
{
  "operationName":"deleteReports"
  "variables":{
    "reportKeys":["<DOCUMENT_ID>"]
  }
  "query":"mutation deleteReports($siteId: ID! $reportKeys: [String]!) {
    {
      deleteReports(reportKeys: $reportKeys)
    }
  }"
}

چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟

---

• بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد.
• استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذکور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟
• ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID⁴ برای شناسه رکوردها.
• طراحی آزمونهایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی.

مراجع

---

• Authorization Cheat Sheet
• Authorization Testing Automation Cheat Sheet

خارجی

• CWE-285: Improper Authorization
• CWE-639: Authorization Bypass Through User-Controlled Key

Footnotes

1. Object ID ↩

2. Broken Object Level Authorization ↩

3. Logged-in User ↩

4. Globally Unique Identifier ↩