API1:2023 نقض مجوزدهی در سطح اشیاء
| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد |
|---|---|---|
| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار |
| مهاجمین می‌توانند از نقاط و توابع آسیب‌پذیر (از منظر مجوزدهی نادرست در سطح اشیا) با دستکاری شناسه شیء ارسالی درون درخواست سوءاستفاده و بهره برداری نمایند. این امر می‌تواند منجر به دسترسی غیرمجاز به داده حساس شود. دسترسی غیرمجاز به داده حساس، مساله‌ای رایج در اپلیکیشن‌های مبتنی بر API است چرا که مولفه سرور غالبا به طور کامل وضعیت کلاینت را رهگیری نمی‌کند و در عوض برای تصمیم گیری درباره دسترسی کلاینت به اشیاء از پارامترهایی نظیر شناسه شی که از سوی خود کلاینت ارسال می‌شوند، تکیه دارند. | این حمله رایج ترین آسیب‌پذیری APIها بوده و بیشترین پیامدها را نیز در پی دارد. مکانیزم‌های مجوزدهی و کنترل دسترسی در اپلیکیشن‌های مدرن، پیچیده و گسترده هستند. حتی اگر اپلیکیشن زیرساخت مناسب را برای کنترل‌های مجوزدهی پیاده‌سازی نماید، ممکن است توسعه دهندگان پیش از دسترسی به اشیا حساس، استفاده از این کنترل‌ها را فراموش نمایند. تشخیص نقایص مربوط به کنترل دسترسی از طریق تست‌های ایستا یا پویا به صورت خودکار غالبا امکان پذیر نیست. | دسترسی غیرمجاز می‌تواند منجر به افشای اطلاعات به طرف‌های غیرمجاز، از دست رفتن داده یا دستکاری آن شود. همچنین دسترسی غیرمجاز به اشیا می‌تواند سبب تحت کنترل گرفتن کامل حساب کاربری توسط مهاجم گردد. |
آیا API از نظر نقض مجوزدهی در سطح اشیاء آسیب‌پذیر است؟
مجوزدهی در سطح اشیا مکانیزمی برای کنترل دسترسی است که غالبا در سطح کد پیاده‌سازی شده و دسترسی کاربر به اشیایی که بایستی به آنها دسترسی داشته باشد را تضمین می‌نماید.
هر تابعی در API که یک شناسه شی دریافت نموده و نوعی عملیات بر روی آن شی انجام می‌دهد، بایستی کنترل‌های مجوزدهی در سطح اشیا را بکار گیرد. این کنترل‌ها باید دسترسی کاربرِ واردشده به انجام عمل درخواستی بر روی شی درخواستی را اعتبارسنجی نمایند.
وجود ایراد و نقصان در این مکانیزم منجر به افشای اطلاعات غیرمجاز، تغییر یا از بین رفتن تمامی داده خواهد شد.
در مسئله‌ی Broken Object Level Authorization (BOLA)، امنیت کاربران در دسترسی به اطلاعات و منابع در سیستم به خطر می‌افتد. این مشکل زمانی رخ می‌دهد که سیستم یک درخواست API حاوی یک شناسه (مثلاً شناسه یک مورد یا اشیاء خاص) را دریافت می‌کند و بدون بررسی دقیق این شناسه و اعتبارسنجی آن، به منابع مرتبط با آن شناسه دسترسی می‌دهد. مهاجمان با تغییر شناسه در درخواست‌های خود می‌توانند به اطلاعاتی دسترسی پیدا کنند که به طور عادی نباید به آنها دسترسی داشته باشند.
مثال‌هایی از سناریوهای حمله
سناریو #1
یک پلتفرم تجارت الکترونیک، برای فروشگاه‌های آنلاین نمودارهای سود فروشگاه‌های میزبانی شده را در قالب یک لیست چندصفحه‌ای ارائه می‌دهد. مهاجم با بررسی درخواست‌های مرورگر، توابعی از API که نقش منبع داده برای نمودارهای مذکور را دارند و الگوی آنها به صورت /shops/{shopName}/revenue_data.json می‌باشد را شناسایی می‌کند. با استفاده از یک تابع دیگر API، مهاجم می‌تواند لیست نام کلیه فروشگاه‌های میزبانی شده را استخراج نماید. همچنین مهاجم با استفاده از یک اسکریپت ساده و جایگزین کردن {shopName} در URL خواهد توانست به داده‌ی فروش هزاران فروشگاه دسترسی یابد.
سناریو #2
یک تولیدکننده خودرو از طریق یک API امکان کنترل از راه دور خودروها را برای ارتباط با تلفن همراه راننده فراهم کرده است. این API به راننده این امکان را می‌دهد که موتور خودرو را از راه دور روشن و خاموش کند و درب‌ها را قفل و باز کند. در این فرآیند، کاربر شماره شناسایی خودرو (VIN) را به API ارسال می‌کند. متأسفانه، API قادر به اعتبارسنجی نمی‌باشد که آیا VIN به ماشینی کاربر وارد شده اختصاص دارد یا نه. این مشکل منجر به وقوع یک آسیب‌پذیری به نام BOLA می‌شود و به این ترتیب مهاجم می‌تواند به خودروهایی دسترسی پیدا کند که به او تعلق ندارند.
سناریو #3
یک سرویس ذخیره‌سازی اسناد آنلاین به کاربران این امکان را می‌دهد که اسناد خود را مشاهده، ویرایش، ذخیره و حذف کنند. هنگامی که کاربری یکی از اسناد خود را حذف می‌کند، یک عملیات درخواستی به نام GraphQL Mutation با استفاده از شناسه (ID) مربوط به سند حذف‌شده به API ارسال می‌شود. این درخواست GraphQL به API اطلاع می‌دهد که یک سند باید حذف شود و API مسئول انجام این عملیات حذف است.
چگونه از آسیب‌پذیری مجوزدهی نادرست در سطح اشیاء پیشگیری کنیم؟
- بکارگیری یک مکانیزم مجوزدهی که بر خط مشی و سلسله مراتب کاربری تمرکز دارد.
- استفاده از یک مکانیزم مجوزدهی برای بررسی اینکه آیا کاربر واردشده مجوز لازم برای انجام عملیات درخواستی بر روی رکورد در تمامی توابعی که از کلاینت، ورودی می‌گیرند تا به رکورد مذکور در پایگاه داده دسترسی داشته باشند را دارا است یا خیر؟
- ارجحیت استفاده از مقادیر تصادفی و غیرقابل پیش بینی بعنوان GUID برای شناسه رکوردها.
- طراحی آزمون‌هایی برای ارزیابی صحت عملکرد مکانیزم‌های مجوزدهی.