سطح حملهای که هیچکس تماشا نمیکند
هر برنامهٔ مدرن بر روی APIها ساخته شده — اتصال فرانتاندها به بکاندها، سرویسها به یکدیگر، و کسبوکارها به شرکای خود. آن بافت پیوندی همچنین یکی از بهطور مداوم مورد سوءاستفادهقرارگرفتهترین سطوح حمله است، دقیقاً به این دلیل که اغلب سریع ساخته میشود و با دقت کمتری نسبت به کد روبهکاربر بازبینی میشود.
اشتباهاتی که به نقضهای واقعی منجر میشوند بهندرت عجیب هستند. آنها همان مشتی مسائل هستند که در پایگاههای کد بیشماری تکرار میشوند.
اشتباهات تکرارشونده
مجوز شکسته در سطح شیء
رایجترین آسیبپذیری واحد API: یک نقطهٔ پایانی بررسی میکند که کاربر احراز هویت شده است، اما نه اینکه مجاز به دسترسی به منبع خاصی که درخواست میکند باشد. یک شناسه در URL را از /orders/1001 به /orders/1002 تغییر دهید، و اگر سرور مالکیت را تأیید نکند، شما به دادهٔ شخص دیگری نگاه میکنید.
افشای بیشازحد داده
یک نقطهٔ پایانی یک شیء کامل پایگاه داده را برمیگرداند — شامل فیلدهای داخلی، هشهای رمز عبور یا دادهٔ کاربران دیگر — زیرا ساختنش سریعتر بود تا فیلترکردن پاسخ به فقط چیزی که فرانتاند واقعاً نیاز دارد. پنهانکردن یک فیلد توسط فرانتاند در رابط کاربری کاری نمیکند اگر پاسخ API هنوز آن را شامل شود.
بدون محدودیت نرخ
بدون محدودیت در تعداد درخواستهایی که یک نقطهٔ پایانی میپذیرد، شکستن رمز عبور با نیروی بیرحم، خراشدادن کل مجموعههای داده، یا غرقکردن سرور بیاهمیت میشود — همه از طریق یک نقطهٔ پایانی کاملاً «مشروع» احراز هویتشده یا عمومی.
اعتماد به اعتبارسنجی سمت کلاینت
منطق اعتبارسنجی که فقط در جاوااسکریپت فرانتاند وجود دارد امنیت نیست — یک ظرافت تجربهٔ کاربری است. هرکسی میتواند کاملاً از فرانتاند عبور کند و درخواستها را مستقیماً به API ارسال کند. هر قاعدهٔ اعتبارسنجی که برای امنیت اهمیت دارد باید سمت سرور اعمال شود.
پیامهای خطای پرگو
ردیابیهای پشتهٔ دقیق یا پیامهای خطای پایگاه داده که به کلاینت برگردانده میشوند هدیهای برای مهاجم هستند — آنها پشتهٔ فناوری شما، ساختار جدول و نقاط شکست دقیق را آشکار میکنند، و یک کاوش کور را به یک کاوش هدایتشده تبدیل میکنند.
APIهای داخلی نسخهبندینشده و مستندنشده که «غیرعمومی» تلقی میشوند
یک API که از نظر فنی قابلدسترسی است اما «از هیچجا لینک نشده» پنهان نیست — فقط هنوز کشفنشده است. امنیت از طریق مبهمبودن بهمحض اینکه کسی یک اسکنر نقطهٔ پایانی پایه اجرا کند شکست میخورد.
خط پایهای که هر API باید داشته باشد
۱. بررسیهای مجوز روی هر تک نقطهٔ پایانی، تأیید نه فقط «آیا این کاربر وارد شده» بلکه «آیا این کاربر این منبع خاص را دارد یا حق آن را دارد». ۲. شکلدهی صریح پاسخ — فقط فیلدهایی که کلاینت واقعاً نیاز دارد را برگردانید، هرگز یک شیء خام پایگاه داده نه. ۳. محدودیت نرخ روی هر نقطهٔ پایانی عمومی و احراز هویتشده، نه فقط فرمهای ورود. ۴. اعتبارسنجی سمت سرور روی همهچیز، رفتار با تمام ورودی کلاینت بهعنوان غیرقابلاعتماد صرفنظر از آنچه فرانتاند قبلاً بررسی کرده. ۵. پیامهای خطای عمومی به کلاینت، با جزئیات واقعی ثبتشده سمت سرور برای اشکالزدایی، نه افشاشده در پاسخ.
نتیجه
شکستهای امنیت API بهندرت حملات پیچیده هستند — آنها اصول اولیهٔ نادیدهگرفتهشدهای هستند که توسط هرکسی که فکر بررسیکردن میکند مورد سوءاستفاده قرار میگیرند. خبر خوب این است که راهحلها بهخوبی درک شدهاند و پیادهسازی آنها گران نیست؛ آنها فقط نیاز دارند که طراحی API از همان ابتدا بهعنوان یک سطح امنیتی در نظر گرفته شود، نه یک فکر ثانویهای که قبل از راهاندازی اضافه شده.
در حال ساخت یا ممیزی یک API هستید و بهطور خاص میخواهید یک نگاه دوم به منطق مجوز داشته باشید؟ آنجا معمولاً جایی است که ریسک واقعی پنهان میشود.