| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد |
|---|---|---|
| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: گسترده/ قابلیت تشخیص: متوسط | پیامد فنی: متوسط / خاص کسب و کار |
| نسخه‌های قدیمی API غالبا اصلاح و بروزرسانی نشده‌اند و از آنجا که از مکانیزم‌های دفاعی نوین موجود در APIهای جدید بهره نمی‌برند، راهی آسان برای دسترسی به سیستم‌ها برای مهاجمین فراهم می‌سازند. در برخی موارد، ابزارهای یا تکنیک‌های نفوذ برای حمله به سیستم‌ها از قبل وجود دارند. در موارد دیگر، ممکن است مهاجمان از طریق یک شخص یا سازمان ثالث که هیچ دلیل قانونی برای به اشتراک گذاری اطلاعات با آن وجود ندارد، به اطلاعات حساس دسترسی یابند. | عدم بروزرسانی مستندات، شناسایی و رفع آسیب پذیری‌ها را دشوارتر می‌کند. همچنین نبود فهرستی از دارایی‌ها و فقدان یک استراتژی مدون برای از دور خارج کردن نسخه‌های قدیمی منجر می‌شود تا سیستم های وصله نشده، مورد استفاده قرار گرفته و در نتیجه آن افشای اطلاعات رخ دهد. امروزه با کمک مفاهیم نوینی نظیر مایکروسرویس‌ها که امکان بکارگیری اپلیکیشن‌ها بصورت مستقل را تسهیل نموده‌اند (نظیر رایانش ابری، k8s یا کوبرنیتس و ...)، یافتن APIهایی که به صورت غیرضروری در معرض دید همگان قرار دارند تبدیل به امری رایج و آسان شده است. استفاده از تکنیک‌هایی مانند Google Dorking، نقض DNS یا استفاده از موتورهای جستجوی ویژه برای انواع مختلف سرورها (دوربین‌های تحت شبکه، روترها، سرورها و غیره) متصل به اینترنت کافی خواهد بود تا مهاجم بتواند اهدافی را کشف کند. | مهاجم می‌تواند از طریق نسخه‌های قدیمی API که کماکان به پایگاه داده‌ی اصلی متصل هستند، به داده‌ی حساس و یا حتی سرور دسترسی یابد. گاهی اوقات نسخه‌ها یا پیاده‌سازی‌های مختلف API به پایگاه داده‌ای مشترک با داده‌های واقعی متصل هستند. عاملان تهدید ممکن است از endpointهای موجود در نسخه‌های قدیمی API برای دستیابی به توابع مدیریتی استفاده کرده و از آسیب‌پذیری‌های شناخته شده بهره‌برداری کنند. |
آیا API از نظر مدیریت نادرست دارایی1ها آسیب‌پذیر است؟
طبیعت متصل و پراکنده APIها و برنامه‌های مدرن چالش‌های جدیدی را به دنبال دارد. سازمان‌ها علاوه بر داشتن درک دقیقی از APIها و endpoint های آنها، باید چگونگی به اشتراک گذاری داده با شرکت‌ها یا اشخاص دیگر را درک کنند. این مسأله به امنیت و حفظ حریم خصوصی داده‌ها مرتبط بوده و نیازمند درک کامل و کنترل دقیق بر روی چگونگی استفاده از داده‌ها و اشتراک آنها با سایر ارتباط‌گیرندگان است.
اجرای چندین نسخه از یک API نیازمند ارائه منابع مدیریتی اضافی می‌باشد که باید برای هر نسخه از API منابع و زیرساخت مجزا فراهم نموده و از نظر امنیتی بر هر کدام نظارت کرد.
یک API در مستنداتش نقاط کور دارد اگر:
- هدف از وجود API نامشخص بوده و پاسخی برای سوال‌های زیر وجود نداشته باشد:
- مستندی برای API وجود ندارد یا بروز نیست.
- برنامه‌ای برای بازنشستگی و از دور خارج شدن هریک از نسخه‌های API وجود ندارد.
- فهرست میزبان4ها وجود ندارد یا قدیمی است.
داشتن دید و لیست‌بندی از چگونگی جریان اطلاعات حساس در سازمان و نحوه تبادل این اطلاعات با شخص‌ها یا سازمان‌های دیگر، نقش مهمی در برنامه واکنش به وقوع یک حادثه امنیتی دارد. این اهمیت به ویژه زمانی ظاهر می‌شود که یک نقض امنیتی از سوی شرکت یا سازمان سومی رخ دهد.
یک API دارای نقطه کور در جریان داده است اگر:
- API جریان داده حساسی را با طرف ثالث به اشتراک می‌گذارد و
- توجیه تجاری یا تأییدی برای این جریان وجود ندارد.
- موجودیت یا دیدگاهی از این جریان وجود ندارد.
- دیدگاه دقیقی از نوع داده حساسی که به اشتراک گذاشته می‌شود، وجود ندارد.
یک شبکه اجتماعی از مکانیزم محدودسازی نرخ ارسال درخواست5 برای جلوگیری از انجام حملات Brute Force توسط مهاجمین جهت حدس توکن‌های تغییر گذرواژه بهره می‌برد. این مکانیزم نه به عنوان بخشی از کد API، بلکه به عنوان مولفه ای مابین کلاینت و API اصلی (در www.socialnetwork.com) پیاده‌سازی شده است. مهاجم یک نسخه بتا از میزبان API (www.mbasic.beta.socialnetwork.com) می‌یابد که از API یکسانی بهره می‌برد و رویه تغییر گذرواژه یکسانی دارد با این تفاوت که در آن هیچ مکانیزمی جهت محدودسازی نرخ درخواست تعبیه نشده است؛ در نتیح...
توسعه‌دهندگان برنامه‌های مستقل می‌توانند با یک شبکه اجتماعی ادغام شوند. به عنوان بخشی از این فرآیند، اجازه‌نامه‌ای به کاربر نهایی ارائه می‌شود تا شبکه اجتماعی بتواند اطلاعات شخصی کاربران را با برنامه مستقل به اشتراک بگذارد. جریان داده بین شبکه اجتماعی و برنامه‌های مستقل، محدود نیست و نظارت کافی بر آن نمی‌شود. درنتیجه برنامه‌های مستقل به جز اطلاعات کاربر، به اطلاعات خصوصی تمام دوستان آنها دسترسی پیدا می‌کنند. یک شرکت مشاوره، برنامه مخربی ایجاد کرده و توانسته از 270،000 کاربر اجازه دسترسی به اطلاعاتشان ر...
- فهرستی از تمامی میزبان‌های API تهیه شده و جنبه‌های مهم هرکدام با تمرکز بر محیط API (محیط تست، توسعه، اجرا یا عملیات)، افراد مجاز به دسترسی شبکه‌ای به میزبان (همه، افراد دخیل یا شرکا) و نسخه API مستند شود.
- فهرستی از سرویس‌های یکپارچه تهیه شده و جنبه‌های مهم این سرویس‌ها نظیر نقش آنها، داده‌ی مبادله شده (جریان داده) و میزان حساسیت آنها مستند شود.
- تمامی جنبه‌های API نظیر نحوه احراز هویت، خطاها، ریدایرکت‌ها، محدودسازی نرخ درخواست، خط مشی‌های اشتراک گذاری متقابل منابع (CORS) و نقاط پایانی یا توابع انتهایی (Endpointها) شامل پارامترها، درخواست‌ها و پاسخ‌ها مستند شوند.
- با بکارگیری و انطباق با استانداردهای باز، فرایند تولید مستند بطور خودکار انجام شده و این فرایند در CI/CD Pipeline تعبیه گردد.
- مستندات API در اختیار افرادی که مجاز به دسترسی به API هستند قرار گیرد.
- از مکانیزم‌های محافظتی خارجی از جمله فایروال‌های امنیت API برای محافظت از تمامی نسخه‌های در معرض دید API (نه فقط نسخه فعلی) استفاده گردد.
- از استفاده همزمان نسخه‌های عملیاتی شده6 و عملیاتی نشده API 7اجتناب شود. اگر این همزمانی اجتناب ناپذیر است، برای نسخه‌های عملیاتی نشده API نیز باید همان حفاظت‌های امنیتی نسخه‌های عملیاتی شده برقرار باشد.
- هنگامی که در نسخه‌های جدیدتر API بهبودهای امنیتی اعمال می‌شود، بایستی فرایند تحلیل ریسک نیز صورت پذیرد تا بتوان تصمیمات لازم در خصوص اقدامات جبرانی برای رفع مشکلات 8امنیتی نسخه‌های قدیمی‌تر را اتخاذ نمود. بعنوان نمونه، آیا می‌توان بدون تحت‌الشعاع قراردادن انطباق‌پذیری API بهبودهای امنیتی را در نسخه‌های قدیمی نیز وارد نمود یا اینکه بایستی تمامی نسخه‌های قدیمی به سرعت از دسترس خارج شده و تمامی کلاینت‌های مجبور به استفاده از آخرین نسخه شوند؟