API7:2019 پیکربندی امنیتی نادرست
عوامل تهدید / مسیر حمله | ضعف امنیتی | پیامد |
---|---|---|
API خاص: قابلیت بهرهبرداری3 | میزان شیوع3 : قابلیت تشخیص3 | پیامد فنی2 : خاص کسب و کار |
مهاجمین غالبا در تلاش برای یافتن حفرههای وصله نشده، توابع رایج یا فایلها و مسیرهای محافظت نشده به منظور دسترسی غیرمجاز به سیستم هستند. | پیکربندی امنیتی نادرست میتواند در هر سطحی از API، از سطح شبکه تا سطح اپلیکشن روی دهد. ابزارهای خودکاری وجود دارند که فرایند تشخیص و بهره برداری از پیکربندیهای نادرست نظیر تشخیص سرویسهای غیرضروری را انجام میدهند. | پیکربندی امنیتی نادرست نه تنها میتواند اطلاعات حساس کاربر را افشا کند بلکه جزئیاتی از سیستم که ممکن است به از دست رفتن کامل سرور منجر شود را نیز در معرض خطر قرار میدهد. |
آیا API از نظر پیکربندی امنیتی نادرست آسیبپذیر است؟
از منظر پیکربندی امنیتی نادرست api آسیب پذیر است اگر:
- ایمن سازی امنیتی مناسب در هر قسمت از پشته اپلیکیشن رعایت نشده یا اپلیکیشن مجوزهای با پیکربندی نادرست روی سرویسهای ابری داشته باشد.
- جدیدترین وصلههای امنیتی نصب نشده و سیستمها کاملا بروز نباشند.
- ویژگی غیرضروری (نظیر افعال اضافی HTTP) فعال باشند.
- امنیت لایه انتقال (TLS) غیرفعال باشد.
- دستورات و الزامات امنیتی (نظیر سرایندهای امنیتی) به سوی کلاینت ارسال نشوند.
- خط مشی اشتراک متقابل منابع (CORS ) وجود نداشته یا به درستی پیادهسازی نشده باشد.
- پیامهای خطا ردپای پشته یا اطلاعات حساس دیگر را افشا نمایند.
مثالهایی از سناریوهای حمله
سناریو #1
مهاجم فایل .bash_history
را (که دستورات مورد استفاده تیم DevOps برای دسترسی به API را در خود دارد) در مسیر root سرور مییابد:
$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='
همچنین مهاجم خواهد توانست توابعی از API که تنها توسط تیم DevOps مورد استفاده قرارگرفته و مستند نشدهاند را نیز بیابد.
سناریو #2
برای هدف قراردادن یک سرویس مشخص، مهاجم از موتورهای جستجوی رایج برای یافتن کامپیوترهایی که مستقیما توسط اینترنت قابل دسترسی هستند بهره میبرد. در نتیجه، مهاجم میزبانی را مییابد که از یک سیستم مدیریت پایگاه داده محبوب استفاده نموده و اقدام به شنود روی پورت پیشفرض آن dbms میکند. از آنجا که میزبان از پیکربندی پیشفرض (که احراز هویت را بطور پیشفرض غیرفعال نموده) استفاده کرده، مهاجم میتواند به میلیونها رکورد حاوی PII، دادههای احرازهویت و ... دست یابد.
سناریو #3
مهاجم با بررسی ترافیک یک اپلیکیشن موبایل متوجه میشود که تمامی ترافیک HTTP بر بستر یک پروتکل ایمن (نظیر TLS) منتقل نمیشود و این موضوع خصوصا در زمان دانلود تصاویر پروفایل صدق میکند. از آنجا که تعامل کاربر با اپلیکیشن دودویی است، علیرغم انتقال ترافیک API بر بستر پروتکلی ایمن، مهاجم خواهد توانست الگویی را در اندازه پاسخ API شناسایی نموده و از آن برای رهگیری ترجیحات کاربر در خصوص محتوای ارائه شده به اپلیکیشن (مثلا تصاویر پروفایل) بهره ببرد.
چگونه از آسیبپذیری پیکربندی امنیتی نادرست پیشگیری کنیم؟
چرخه حیات API بایستی شامل موارد زیر باشد:
- فرایندی تکرار شونده برای ایمن سازی API که منجر به پیادهسازی سریع و آسان یک محیط ایمن شود.
- فرایندی برای بازبینی و بروزرسانی پیکربندیها در سراسر پشته API؛ این بازبینی بایستی موارد از جمله بازبینی هماهنگی بین فایلها، مولفههای API و سرویسهای ابری (نظیر مجوزهای باکتهای S3) را دربرگیرد.
- برقراری یک کانال ارتباطی ایمن برای دسترسی تمامی تعاملات API به داراییهای ایستا (نظیر تصاویر).
- خودکار جهت ارزیابی پیوسته و مداوم اثربخشی پیکربندی و تنظیمات اعمال شده در سراسر محیط API و اپلیکیشن.
بعلاوه:
- برای جلوگیری از ارسال رهگیری رویدادهای استثنا و سایر دادههای ارزشمند به مهاجم، در صورت امکان برای تمامی پاسخهای API (از جمله خطاها) الگوهای محموله مشخص تعریف و اعمال گردد.
- حصول اطمینان از اینکه API فقط به افعال HTTP مدنظر توسعه دهنده پاسخ می دهد و غیرفعال کردن سایر افعال (نظیر
HEAD
). - APIهایی که انتظار میرود دسترسی به آنها از طریق کلاینتهای مبتنی بر مرورگر (مثلا فرانت WebApp) باشد، بایستی خط مشی CORS مناسب را بکار گیرند.
مراجع
OWASP
- OWASP Secure Headers Project
- OWASP Testing Guide: Configuration Management
- OWASP Testing Guide: Testing for Error Codes
- OWASP Testing Guide: Test Cross Origin Resource Sharing