ساخت قلعه با امنیت یک چادر (Build a Fortress with the Security of a Tent)
APIها از سال ۲۰۱۰ به شدت تغییر کرده‌اند، زمانی که بسیاری از بهترین شیوه‌ها و دانش پذیرفته شده‌ای که اکنون به کار می‌بریم، برای اولین بار پیاده‌سازی شدند. جیکوب آیدسکوگ، مدیر فناوری Curity، این معماری را به «پیاز» تشبیه می‌کند، به دلیل حلقه‌های متحدالمرکز فایروال‌ها، شبکه‌ها و سرورها. مشکل این است که پیاز پیاده‌سازی بسیار دشواری در دنیای غیرمتمرکز دستگاه‌های موبایل، سرورهای ابری و میکروسرویس‌ها دارد. این تحول نیازمند رویکردی کاملاً متفاوت برای امنیت API است.
این موضوع سخنرانی آیدسکوگ در Platform Summit 2024 با عنوان “چگونه یک قلعه بسازیم با امنیت یک چادر” بود. در ادامه، نکات اساسی از سخنرانی آیدسکوگ برای پیاده‌سازی در طراحی APIها آورده شده است.
استفاده از معماری مبتنی بر توکن
آیدسکوگ سخنرانی خود را با بحث درباره تکامل APIها پس از رونق دستگاه‌های موبایل circa ۲۰۱۲ آغاز کرد. آغاز غیرمتمرکزسازی با ظهور احراز هویت مبتنی بر توکن مانند OAuth 2.0 همراه بود. معماری مبتنی بر توکن کلید بسیاری از مسائل امنیتی مورد بحث در این ارائه است.
آیدسکوگ دو نوع توکن را معرفی می‌کند. اولی Bearer Token است که می‌توان مانند پول پیدا شده روی زمین از آن استفاده کرد. دومی Holder of Key (HoK) یا Proof of Possession (PoP) است، که نیاز دارد سرور API تأیید کند که کاربر همان کسی است که ادعا می‌کند. آیدسکوگ قویاً از HoK و PoP حمایت می‌کند و بخش عمده‌ای از سخنرانی خود را به توضیح نحوه پیاده‌سازی این معماری اختصاص می‌دهد.
معماری مبتنی بر توکن همچنین جزو اجزای حیاتی معماری Zero-Trust است، که در دنیایی که به شدت وابسته به معماری ابری و میکروسرویس‌ها است، رایج شده است. در غیر این صورت، یک کاربر غیرمجاز که به Bearer Token دست پیدا کند، می‌تواند به کل شبکه دسترسی پیدا کند.
شناخت مخاطب
APIها بسیار گسترده‌تر از گذشته شده‌اند. آن‌ها دیگر محدود به درخواست‌های HTTP و اشیاء JSON نیستند. بلکه، APIها بخش حیاتی از اپلیکیشن‌های تک‌صفحه‌ای (SPA)، اپلیکیشن‌های موبایل و وب‌سایت‌های سنتی هستند. این خبر خوبی برای توسعه‌دهندگان API است که می‌خواهند مخاطب وسیع‌تری داشته باشند، اما نگرانی‌هایی درباره امنیت API ایجاد می‌کند.
این نگرانی‌ها شامل «چادرها» می‌شود، که نام مستعار آیدسکوگ برای APIها و برنامه‌های شخص ثالث است که با یک API تعامل دارند. توسعه‌دهندگان API باید اطمینان حاصل کنند که این چادرها و APIهای آن‌ها امن هستند، زیرا امنیت یک اکوسیستم API به ضعیف‌ترین حلقه آن بستگی دارد.
ادغام FAPI
آیدسکوگ به چندین مورد استفاده از APIها اشاره می‌کند که در آن‌ها هویت به ویژه اهمیت دارد. او ابتدا Financial-Grade APIs (FAPI) را معرفی می‌کند، پروتکلی که نیاز به استفاده از JSON Web Tokens (JWTs) دارد. FAPI همچنین به طراحان API اجازه می‌دهد سطوح دسترسی مختلفی از پروفایل پایه تا پیشرفته و اعطای مجوز را فعال کنند. همچنین به عنوان یک لایه انتزاعی اضافی بین کاربر و منبع نهایی عمل می‌کند و برای تراکنش‌های مالی مناسب است.
پذیرش هویت غیرمتمرکز
تنها امن‌سازی API با توکن‌های ناشناس اغلب کافی نیست. بدون پیاده‌سازی آنچه آیدسکوگ Proof of Possession یا PoP می‌نامد، کسی می‌تواند به توکن مجاز دسترسی پیدا کند که به او «کلیدهای پادشاهی» را می‌دهد. او چندین روش برای ادغام مدیریت هویت در مجوزدهی API پیشنهاد می‌کند.
اولین روش، sender-constrained tokens است که کاربر را به اتصال TLS مشترک بین کلاینت و سرور مجوزدهی متصل می‌کند.
روش دوم، که آیدسکوگ جزئیات بیشتری درباره آن ارائه می‌دهد، token-handler pattern یا همان backend for frontend است، که بیشتر مسائل امنیتی ناشی از SPA و اپلیکیشن‌های موبایل را با اتصال یک بک‌اند ساده حل می‌کند. این روش مشکلات هویت را با بازگرداندن امکان استفاده از احراز هویت مبتنی بر کوکی حل می‌کند.
اجتناب از مجوزدهی در مرورگر
مجوزدهی مبتنی بر مرورگر با رشد SPA و اپلیکیشن‌های موبایل محبوب شد. مرورگر در معرض انواع آسیب‌پذیری‌های امنیتی است. آیدسکوگ حتی می‌گوید: «مرورگر یک محیط خصمانه است.»
Cross-site scripting (XSS) به مهاجمان اجازه می‌دهد با تزریق چند خط جاوااسکریپت به مرورگر به دسترسی غیرمجاز برسند. در یکی از مثال‌ها، مهاجم توانست کل بک‌اند سازمان را با دو تگ تصویر ساده کپی کند.
این تنها شروع مشکلاتی است که XSS می‌تواند ایجاد کند. پس از دسترسی غیرمجاز، مهاجم می‌تواند توکن‌های جدید صادر کرده و توکن‌های موجود را تازه کند. به علاوه، XSS تقریباً غیرقابل ردیابی است، زیرا سیستم با استفاده از توکن‌های معتبر دسترسی می‌یابد.
آیدسکوگ همچنین درباره blind submission هشدار می‌دهد، حمله‌ای که در آن کد مخرب در یک فرم وارد می‌شود و بعداً اجرا می‌شود. حذف مرورگر از معادله تقریباً تمام این آسیب‌پذیری‌ها را از بین می‌برد.
سخت‌سازی اپلیکیشن‌های موبایل
آیدسکوگ سخنرانی خود را با توصیه‌هایی درباره امن‌سازی اپلیکیشن‌های موبایل به پایان می‌رساند. او اشاره می‌کند که سیستم‌عامل‌های موبایل ابزارهایی برای امن‌سازی اپ‌ها دارند، اما توسعه‌دهندگان از آن‌ها استفاده نمی‌کنند.
او استفاده از attestation را توصیه می‌کند، که برای iOS و Android موجود است و از تراشه سخت‌افزاری دستگاه موبایل برای تأیید تراکنش‌ها استفاده می‌کند. هنگامی که اپلیکیشن‌های موبایل شما امن شدند، می‌توانید به طور کامل از APIها با اطمینان بهره‌برداری کنید.
نتیجه‌گیری
یک API تنها به اندازه ضعیف‌ترین حلقه خود امن است. زمانی که یک API در حال استفاده است، هر کاربری که پروتکل‌های امنیتی مناسب را رعایت نکند، می‌تواند کل سازمان شما را در معرض خطر قرار دهد. حتی ممکن است مسئولیت قانونی داشته باشید اگر API شما به هر نحوی در یک نقض داده‌ها دخیل باشد.
با پیاده‌سازی استراتژی‌های پیشنهادی آیدسکوگ، می‌توانید از بازار در حال انفجار APIها به طور کامل بهره ببرید و همزمان کاربران تجاری و مشتریان را ایمن نگه دارید.
