تاثیر
APIهای در معرض خطر به مهاجمان اجازه میدهند تا رابطهای کاربری را دور بزنند و مستقیماً با پایگاههای داده و سرویسهای باطن [S1] تعامل داشته باشند. این میتواند منجر به استخراج غیرمجاز داده، تصاحب حسابها از طریق brute-force، یا در دسترس نبودن سرویس به دلیل اتمام منابع شود [S3][S5].
علت اصلی
علت اصلی اصلی، قرار گرفتن در معرض منطق داخلی از طریق نقاط پایانی است که فاقد اعتبار و حفاظت کافی [S1] هستند. توسعهدهندگان اغلب تصور میکنند که اگر یک ویژگی در رابط کاربری قابل مشاهده نباشد، ایمن است، که منجر به شکسته شدن کنترلهای دسترسی [S2] و خطمشیهای مجاز CORS میشود که به بسیاری از مبداهای [S4] اعتماد دارند.
فهرست چک امنیتی ضروری API
- اجرای کنترل دسترسی دقیق: هر نقطه پایانی باید تأیید کند که درخواست کننده مجوزهای مناسب برای منبع خاصی را دارد که به آن دسترسی دارد [S2].
- محدود کردن نرخ پیاده سازی: با محدود کردن تعداد درخواست هایی که مشتری می تواند در یک بازه زمانی خاص [S3] انجام دهد، در برابر سوء استفاده خودکار و حملات DoS محافظت کنید.
- CORS را به درستی پیکربندی کنید: از استفاده از مبداهای عام (
*) برای نقاط پایانی تأیید شده خودداری کنید. برای جلوگیری از نشت داده های بین سایتی [S4]، مبداهای مجاز را به صراحت تعریف کنید. - مشاهده نقطه پایانی حسابرسی: به طور مرتب نقاط پایانی "مخفی" یا غیرمستندی را که ممکن است عملکرد حساس [S1] را نشان دهد، اسکن کنید.
چگونه FixVibe آن را آزمایش می کند
FixVibe اکنون این چک لیست را از طریق چندین بررسی زنده پوشش می دهد. کاوشگرهای دارای دروازه فعال محدودیت نرخ نهایی، CORS، CSRF، تزریق SQL، نقاط ضعف جریان تأیید و سایر مشکلات مربوط به API را فقط پس از تأیید آزمایش می کنند. چکهای غیرفعال سرصفحههای امنیتی، اسناد عمومی API و قرار گرفتن در معرض OpenAPI و اسرار موجود در بستههای مشتری را بررسی میکنند. اسکنهای Repo بررسی ریسک سطح کد را برای CORS ناامن، درون یابی خام SQL، اسرار ضعیف JWT، استفاده از JWT فقط برای رمزگشایی، شکافهای امضای وب هوک، و شکافهای امضای وب هوک اضافه میکنند.