برترین آسیب پذیری های OATH API
آسیب‌پذیری‌های برتر OATH API: مقدمه
وقتی صحبت از اکسپلویت ها می شود، API ها بهترین مکان برای شروع هستند. API دسترسی معمولا از سه بخش تشکیل شده است. کلاینت ها توکن هایی را توسط یک سرور مجوز صادر می کنند که در کنار API ها اجرا می شود. API نشانه های دسترسی را از مشتری دریافت می کند و قوانین مجوز خاص دامنه را بر اساس آنها اعمال می کند.
نرم افزارهای مدرن در برابر انواع خطرات آسیب پذیر هستند. به سرعت در مورد جدیدترین سوء استفاده ها و نقص های امنیتی ادامه دهید. داشتن معیارهایی برای این آسیب پذیری ها برای اطمینان از امنیت برنامه قبل از وقوع حمله ضروری است. برنامه های شخص ثالث به طور فزاینده ای به پروتکل OAuth متکی هستند. به لطف این فناوری، کاربران تجربه کاربری کلی بهتر و همچنین ورود و مجوز سریع‌تری خواهند داشت. ممکن است از مجوزهای معمولی ایمن تر باشد زیرا کاربران مجبور نیستند اعتبار خود را با برنامه شخص ثالث برای دسترسی به یک منبع مشخص افشا کنند. در حالی که خود پروتکل ایمن و امن است، روش اجرای آن ممکن است شما را برای حمله باز بگذارد.
هنگام طراحی و میزبانی APIها، این مقاله بر روی آسیب‌پذیری‌های معمولی OAuth و همچنین کاهش‌های امنیتی مختلف تمرکز دارد.
مجوز سطح شیء شکسته
در صورت نقض مجوز، سطح حمله گسترده ای وجود دارد زیرا API ها دسترسی به اشیا را فراهم می کنند. از آنجایی که موارد قابل دسترسی API باید احراز هویت شوند، این امر ضروری است. بررسی های مجوز سطح شی را با استفاده از یک دروازه API اجرا کنید. فقط افرادی که دارای اعتبار مجوز مناسب هستند باید اجازه دسترسی داشته باشند.
احراز هویت خراب کاربر
توکن های غیرمجاز یکی دیگر از راه های متداول مهاجمان برای دسترسی به API ها هستند. سیستم‌های احراز هویت ممکن است هک شوند یا یک کلید API ممکن است به اشتباه در معرض دید قرار گیرد. نشانه های احراز هویت ممکن است باشد مورد استفاده هکرها برای به دست آوردن دسترسی افراد را فقط در صورتی احراز هویت کنید که بتوان به آنها اعتماد کرد و از رمزهای عبور قوی استفاده کنید. با OAuth، می توانید فراتر از کلیدهای API صرف بروید و به داده های خود دسترسی داشته باشید. همیشه باید به این فکر کنید که چگونه وارد و خارج می شوید. OAuth MTLS Sender Constrained Tokens ممکن است همراه با Mutual TLS استفاده شود تا تضمین کند که کلاینت‌ها در هنگام دسترسی به ماشین‌های دیگر، رفتار نامناسبی نشان نمی‌دهند و توکن‌ها را به طرف نادرست ارسال نمی‌کنند.
ارتقاء API:
قرار گرفتن در معرض بیش از حد داده ها
هیچ محدودیتی در تعداد نقاط پایانی که ممکن است منتشر شوند وجود ندارد. بیشتر اوقات، همه ویژگی ها در دسترس همه کاربران نیست. با افشای داده های بیش از حد ضروری، خود و دیگران را در معرض خطر قرار می دهید. از افشای موارد حساس خودداری کنید اطلاعات تا زمانی که کاملا ضروری باشد. توسعه دهندگان ممکن است با استفاده از OAuth Scopes و Claims مشخص کنند که چه کسی به چه چیزی دسترسی دارد. ادعاها ممکن است مشخص کنند که کاربر به کدام بخش از داده ها دسترسی دارد. کنترل دسترسی ممکن است با استفاده از یک ساختار استاندارد در همه APIها ساده تر و مدیریت آن آسان تر شود.
فقدان منابع و محدودیت نرخ
کلاه سیاه اغلب از حملات انکار سرویس (DoS) به عنوان یک روش بی رحمانه برای غلبه بر سرور و در نتیجه کاهش زمان کار آن به صفر استفاده می کند. بدون هیچ محدودیتی در منابعی که ممکن است فراخوانی شوند، یک API در برابر یک حمله ناتوان کننده آسیب پذیر است. با استفاده از یک دروازه API یا ابزار مدیریت، می‌توانید محدودیت‌های نرخ را برای APIها تعیین کنید. فیلتر و صفحه بندی باید گنجانده شود و همچنین پاسخ ها محدود شوند.
پیکربندی اشتباه سیستم امنیتی
دستورالعمل‌های مختلف پیکربندی امنیتی به دلیل احتمال زیاد پیکربندی نادرست امنیتی، نسبتاً جامع هستند. تعدادی از چیزهای کوچک ممکن است امنیت پلتفرم شما را به خطر بیندازند. به عنوان مثال، ممکن است کلاه‌های سیاه با اهداف پنهانی اطلاعات حساسی را که در پاسخ به سؤالات نادرست ارسال می‌شوند، کشف کنند.
واگذاری دسته جمعی
فقط به این دلیل که یک نقطه پایانی به طور عمومی تعریف نشده است، به این معنی نیست که توسعه‌دهندگان نمی‌توانند به آن دسترسی داشته باشند. یک API مخفی ممکن است به راحتی توسط هکرها رهگیری و مهندسی معکوس شود. به این مثال اولیه نگاه کنید، که از یک توکن حامل باز در یک API "خصوصی" استفاده می کند. از سوی دیگر، اسناد عمومی ممکن است برای چیزی وجود داشته باشد که منحصراً برای استفاده شخصی باشد. اطلاعات افشا شده ممکن است توسط کلاه سیاه نه تنها برای خواندن، بلکه برای دستکاری ویژگی‌های شی مورد استفاده قرار گیرد. هنگامی که به دنبال نقاط ضعف احتمالی در دفاع خود هستید، خود را یک هکر در نظر بگیرید. فقط به کسانی که حقوق مناسبی دارند اجازه دسترسی به آنچه بازگردانده شده است. برای به حداقل رساندن آسیب پذیری، بسته پاسخ API را محدود کنید. پاسخ دهندگان نباید پیوندهایی را که کاملاً ضروری نیستند اضافه کنند.
API تبلیغ شده:
مدیریت نامناسب دارایی
گذشته از افزایش بهره وری توسعه دهندگان، نسخه های فعلی و اسناد برای ایمنی شما ضروری هستند. برای معرفی نسخه های جدید و از بین رفتن API های قدیمی از قبل آماده شوید. به جای اینکه اجازه دهید API های قدیمی تر در حال استفاده باقی بمانند، از API های جدیدتر استفاده کنید. یک مشخصات API می تواند به عنوان منبع اصلی حقیقت برای مستندات استفاده شود.
تزریق
API ها در برابر تزریق آسیب پذیر هستند، اما برنامه های توسعه دهنده شخص ثالث نیز آسیب پذیر هستند. ممکن است از کد مخرب برای حذف داده ها یا سرقت اطلاعات محرمانه مانند رمزهای عبور و شماره کارت اعتباری استفاده شود. مهمترین درسی که باید از این موضوع گرفت این است که به تنظیمات پیش فرض وابسته نباشید. مدیریت یا تامین کننده دروازه شما باید بتواند نیازهای برنامه منحصر به فرد شما را برآورده کند. پیام های خطا نباید حاوی اطلاعات حساس باشد. برای جلوگیری از نشت اطلاعات هویتی در خارج از سیستم، نام مستعار زوجی باید در توکن ها استفاده شود. این تضمین می کند که هیچ مشتری نمی تواند برای شناسایی یک کاربر با هم کار کند.
ثبت و نظارت ناکافی
هنگامی که یک حمله انجام می شود، تیم ها به یک استراتژی واکنش سنجیده نیاز دارند. اگر یک سیستم ثبت و نظارت قابل اعتماد وجود نداشته باشد، توسعه‌دهندگان به سوء استفاده از آسیب‌پذیری‌ها ادامه خواهند داد، بدون اینکه گرفتار شوند، که این امر باعث افزایش ضرر و آسیب به درک عمومی از شرکت می‌شود. یک استراتژی دقیق نظارت API و تست نقطه پایانی تولید را اتخاذ کنید. آزمایش‌کنندگان کلاه سفید که در مراحل اولیه آسیب‌پذیری‌ها را پیدا می‌کنند، باید با یک طرح جایزه پاداش بگیرند. دنباله گزارش ممکن است با گنجاندن هویت کاربر در تراکنش‌های API بهبود یابد. اطمینان حاصل کنید که تمام لایه‌های معماری API شما با استفاده از داده‌های Access Token ممیزی می‌شوند.
نتیجه
معماران پلتفرم ممکن است با پیروی از معیارهای آسیب پذیری تعیین شده، سیستم های خود را برای نگه داشتن یک قدم جلوتر از مهاجمان مجهز کنند. از آنجا که APIها ممکن است دسترسی به اطلاعات شناسایی شخصی (PII) را فراهم کنند، حفظ امنیت چنین خدماتی هم برای ثبات شرکت و هم برای انطباق با قوانینی مانند GDPR ضروری است. هرگز توکن های OAuth را مستقیماً از طریق یک API بدون استفاده از دروازه API و رویکرد توکن فانتوم ارسال نکنید.
API تبلیغ شده:
