پرش به محتویات

API4:2019 کمبود منابع و نبود محدودیت بر نرخ ارسال

عوامل تهدید/مسیر حمله ضعف امنیتی پیامد
API خاص: قابلیت بهره‌برداری2 میزان شیوع3 : قابلیت تشخیص3 پیامد فنی2 : خاص کسب و کار
بهره برداری از این آسیب‌پذیری نیاز به ارسال درخواست‌های ساده‌ای به سوی API دارد و به احراز هویت هم نیازی نیست. کافی است تعدادی درخواست هم‌زمان از یک ماشین و یا با استفاده از منابع رایانش ابری به سوی API ارسال گردد تا بتوان از این آسیب‌پذیری بهره برد. یافتن APIهایی که محدودسازی نرخ ارسال را بکار نگرفته یا محدودیت‌های اعمال شده آنها ناکافی است، کار دشواری نیست. بهره برداری از این آسیب‌پذیری می‌تواند منجر به بروز DoS شده، در نتیجه API را از پاسخ به درخواست‌ها باز دارد و یا حتی آن را از دسترس خارج نماید.

آیا API از نظر کمبود منابع و نبود محدودیت بر نرخ ارسال ‌‌آسیب‌پذیر است؟

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

  • اجرای محدودیت زمانی (time out)
  • حداکثر میزان حافظه قابل تخصیص
  • تعداد توصیف‌گر فایل‌‌ها
  • تعداد پردازه‌‌ها
  • اندازه محموله در درخواست‌‌ها (مثلا در هنگام آپلود)
  • تعداد درخواست‌‌ها به ازای کلاینت یا منبع
  • تعداد رکوردهایی که به ازای یک درخواست در یک صفحه نمایش داده می‌شوند.

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

سناریو #1

مهاجم از طریق ارسال یک درخواست POST به /api/v1/images اقدام به آپلود یک تصویر بزرگ می‌نماید. بعد از اتمام آپلود، API از روی تصویر آپلود شده تصاویرانگشتی متعددی با اندازه‌‌های مختلف ایجاد می نماید. به دلیل اندازه تصویر آپلودشده، حافظه‌ی دردسترس در خلال فرایند ایجاد تصاویر انگشتی تحت فشار قرار گرفته و API به وضعیت غیرپاسخگو می‌رسد.

سناریو #2

اپلیکیشنی لیست کاربران را در UI با محدودیت 200 کاربر در صفحه نمایش می‌دهد. لیست این کاربران از طربق ارسال پرس و جوی زیر از سرور دریافت می‌گردد: /api/users?page=1&size=200. در اینجا مهاجم می‌تواند با تغییر پارامتر size به 200 000، مشکلاتی در عملکرد پایگاه داده پدید آورده و API را به وضعیت غیرپاسخگو برساند. در این حالت API قادر به پاسخگویی به هیچ درخواستی نخواهد بود (همان DoS). همین سناریو را می‌توان به طریق مشابه برای ایجاد حملات سرریز Integer و سرریز Buffer استفاده نمود.

چگونه از ‌‌آسیب‌پذیری کمبود منابع و نبود محدودیت بر نرخ ارسال پیشگیری کنیم؟

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

مراجع

OWASP

خارجی