APIها شهرتی برای ضعیفترین حلقه در امنیت سایبری سازمانها دارند. این میتواند به یک پیشگویی خودتحققبخش تبدیل شود، زیرا آسیبپذیریهای فرضی APIها آنها را به هدفی محبوب برای مهاجمان بالقوه و مجرمان سایبری تبدیل میکند. این میتواند انواع مسائل امنیتی را ایجاد کند، زیرا APIها میتوانند با استفاده از فراخوانیهای معتبر API، حجم عظیمی از اطلاعات حساس را فاش کنند اگر سیستم شما به درستی تنظیم نشده باشد.
دانستن فراخوانیهای API رایج مورد استفاده توسط مجرمان سایبری، بخش مهمی از ایمنسازی APIهای شما و اجتناب از حملات API است. نظارت بر ترافیک API به طور شرورانهای پیچیده است، زیرا اکثر ترافیک API واقعاً مجاز است، در حالی که برخی واقعاً ناامن است. دانستن فراخوانیهای API دقیق مورد استفاده توسط مهاجمان به متخصصان امنیت سایبری اجازه میدهد تا فراخوانیهای API مشکوک و ترافیک را علامتگذاری یا در فهرست سیاه قرار دهند.
API متاداده نمونه ابری
بسیاری از خدمات مبتنی بر ابر، مانند VMهای ابری یا کانتینرها، یک سرویس محلی برای ارائه متاداده یا، در شرایط خاص، حتی اعتبارهای کوتاهمدت دارند. اگر مهاجمی بتواند به سرویس http://169.254.169.254 دسترسی پیدا کند، مهاجمان میتوانند بالقوه درخواستهای HTTP را با استفاده از تکنیکهایی مانند جعل درخواست سمت سرور (SSRF)، کانتینر به خطر افتاده، یا فرآیند به خطر افتاده برای ارتقای دسترسی خود انجام دهند.
برای کمک به حفاظت در برابر حملات غیرمجاز API متاداده نمونه ابری، ممکن است سرویس http://169.254.169.254 را کاملاً در فهرست سیاه قرار دهید، در حالی که کاربران یا آدرسهای IP مجاز به دسترسی را در فهرست سفید قرار دهید. برای کاربران مجاز، ممکن است یک مدل رفتاری ایجاد کنید، که میتواند برای هشدار به تیم امنیت سایبری شما در صورت وجود رفتار غیرعادی از یک کاربر یا IP خاص استفاده شود. نظارت بر ایجاد منابع ابری غیرعادی نیز میتواند به راهحل امنیت سایبری شما اطلاع دهد که http://169.254.169.254 به خطر افتاده است.
برای حفاظت بیشتر در برابر حملات غیرمجاز API متاداده نمونه ابری، باید دسترسی به متاداده را تا حد ممکن محدود کنید. همچنین میتوانید امنیت متاداده بهبودیافته را با استفاده از پروتکلهای امنیتی مدرن مانند IMDSv2، یا مدیریت هویت و دسترسی کمترین امتیاز (IAM) پیادهسازی کنید.
APIهای REST ذخیرهسازی شیء
بسیاری از APIها گاهی میتوانند سوءاستفاده شوند تا اشیاء ذخیرهشده در یک دایرکتوری را بخوانند، بنویسند، یا فهرست کنند. این میتواند به کاربران غیرمجاز، مهاجمان، و مجرمان سایبری اجازه دهد تا دادههای حساس را صادر و سپس ذخیره کنند، بارهای مفید را میزبانی کنند، یا از فهرستهای کنترل دسترسی (ACL) نادرست پیکربندیشده سوءاستفاده کنند. نقاط انتهایی عمومی GET یا PUT، و عملیات فهرستبندی روی APIهای ذخیرهسازی شیء، به ویژه در معرض خطر هستند.
روش HTTP PUT یکی از نشانههای سوءاستفاده از API REST ذخیرهسازی شیء است. درخواستهای PUT بزرگ یا ترافیک از مکان غیرعادی، نشانهای است که یک نقطه انتهایی تحت حمله است. حجم زیاد درخواستهای عملیات فهرستبندی دیگری است. تغییرات در ACL نشانه دیگری است که کاربران غیرمجاز در حال تلاش برای دسترسی به یک نقطه انتهایی هستند.
مثالی از یک فراخوانی API REST ذخیرهسازی ابری غیرمجاز ممکن است فراخوانی API به نقطه انتهایی مانند https://objectstorage.af-johannesburg-1.oraclecloud.com اوراکل بدون اعتبارهای مناسب باشد. فراخوانیها بدون متغیر ?username یا access_token در کوئری میتوانند به عنوان نشانهای از تلاش برای کسب دسترسی غیرمجاز علامتگذاری شوند.
برای کمک به کاهش ریسکهای API ذخیرهسازی شیء، بهترین شیوههای ACL سطل/شیء را پیادهسازی کنید، که عمومی را به طور پیشفرض رد میکند. فعالسازی لاگگیری با استفاده از ابزارهایی مانند S3 Access Logs یا CloudTrail به کاهش حملات API REST ذخیرهسازی شیء کمک میکند، زیرا به تیم امنیت سایبری شما اجازه میدهد فهرستی از کاربران مجاز برای یک نقطه انتهایی ایجاد کند. تنظیم هشدار طول عمر روی منابع ACL راه دیگری برای حفاظت از API REST ذخیرهسازی شیء است.
سرور API Kubernetes
سرور API Kubernetes قلب صفحه کنترل Kubernetes است، که به کاربران دسترسی به عملیات قدرتمندی مانند اجرای دستورات، فورواردینگ پورتها، بازیابی لاگها، و ایجاد یا تغییر منابع میدهد. قدرت و دسترسی گسترده آن، سرور API Kubernetes را به هدفی اصلی برای مهاجمان تبدیل میکند. اگر کاربر غیرمجاز اعتبارها یا توکنهای دسترسی را به خطر بیندازد یا کنترل دسترسی مبتنی بر نقش (RBAC) به درستی تنظیم نشده باشد، مهاجم میتواند از API برای اجرای دستورات داخل کانتینرها، گسترش در سراسر کلاستر، یا دزدیدن اسرار از بارهای کاری دیگر سوءاستفاده کند.
دسترسی غیرمجاز اغلب ردپایی به جا میگذارد. درخواستهای exec یا portforward غیرعادی، فراخوانیهای API از آدرسهای IP یا عوامل کاربر غیرمنتظره، و ایجاد ناگهانی پادهای privileged یا حسابهای سرویس همه نشانههای دسترسی مخرب هستند. به طور مشابه، تشدید غیرمجاز پیوندهای RBAC نشانه قوی است که کسی در حال تلاش برای کسب کنترل بیشتر از آنچه باید است.
پیادهسازی رویکرد لایهای به امنیت سایبری یکی از رایجترین دفاعها در برابر حملات API Kubernetes است. RBAC باید برای اجازه دادن به اصول کمترین امتیاز سختگیرانه تنظیم شود، و اطمینان حاصل شود که هیچ کاربر یا حساب سرویسی بیش از آنچه نیاز دارد دسترسی ندارد. دسترسی به kube-apiserver خود نیز باید محدود شود، و ایدهآل این است که آن را پشت شبکههای خصوصی و با فایروالینگ سختگیرانه اجرا کنید. توکنهای حساب سرویس نیز باید به طور منظم چرخش داده شوند تا ریسک به خطر افتادن بلندمدت کاهش یابد. لاگگیری ممیزی نیز باید فعال شود، و عملیات حساس مانند exec و portforward را به دقت نظارت کند، و سیاستهای شبکه و استانداردهای امنیت پاد باید برای محدود کردن حرکت در صورت ورود مهاجم اعمال شوند.
یک فراخوانی API غیرمجاز به سرور API Kubernetes ممکن است مانند درخواستی برای اجرای یک شل داخل یک پاد پایگاه داده تولیدی به نظر برسد:
POST /api/v1/namespaces/prod/pods/db-0/exec?command=/bin/sh&container=db&stdin=true&stdout=true HTTP/1.1این فراخوانی مشکوک است زیرا از آدرس IP غیرمجاز میآید. درخواست برای راهاندازی یک شل تعاملی نشانه واضح دیگری است. افزودن هر کدام به سیستم هشدار امنیت سایبری شما میتواند تیم امنیت سایبری شما را در صورت تلاش هر کسی برای دسترسی به API Kubernetes بدون دسترسی مناسب هشدار دهد.
نقاط انتهایی احراز هویت و توکن
نقاط انتهایی احراز هویت و توکن مانند POST /oauth/token، نقاط انتهایی ادعای زبان علامتگذاری ادعای امنیتی (SAML)، یا هر مسیر ورود مورد استفاده توسط یک API، مسیرهای رایجی هستند که برنامههای اعتبار و کاربران برای دسترسی به سیستمهای شما استفاده میکنند. از آنجایی که این نقاط انتهایی برای ایجاد توکنهای دسترسی، کوکیهای جلسه، یا ادعاهایی استفاده میشوند که دسترسی مداوم اعطا میکنند، آنها هدفی بسیار جذاب برای مهاجمانی هستند که به دنبال نقض در امنیت سایبری شما هستند. تکنیکهایی مانند پر کردن اعتبار، اسپری رمز عبور، استفاده مجدد از توکنهای تازهسازی دزدیدهشده، یا بازپخش ادعاهای ورود واحد (SSO) یا SAML میتواند به مهاجم اجازه دهد اعتبارهای معتبر به دست آورد و برای مدت طولانی داخل محیط شما بماند.
نشانههای سوءاستفاده از نقاط انتهایی احراز هویت و توکن تمایل به رفتاری و زمینهای دارند. افزایش تلاشهای ورود شکستخورده علیه حسابهای متعدد یکی از نشانهها است، همانند توکنهای صادرشده از عوامل کاربر یا کشورهای ناآشنا، توکنهای مجاز مورد استفاده توسط آدرسهای IP ناهنجار، یا تازهسازیهای غیرعادی مکرر و جلسات بلندمدت. هر کدام از این الگوها میتواند نشاندهنده حملات اعتبار خودکار، استفاده از اعتبارهای دزدیدهشده، یا جک کردن جلسات باشد.
دفاع از این نقاط انتهایی نیازمند پیشگیری و تشخیص است. محدودیت نرخ و محدود کردن سطح حساب هر دو تکنیک مفید برای توقف تلاشهای خرابکاری یا brute-force هستند. احراز هویت چندعاملی برای جریانهای مجوز حساس نیز همینطور. طول عمر کوتاه برای توکنها و درمان توکنهای تازهسازی به عنوان بسیار حساس روشهای رایج دیگری برای ایمنسازی نقاط انتهایی مجوز هستند. نظارت بر توکنهای صادرشده به آدرسهای IP یا مناطق جغرافیایی غیرعادی راه دیگری برای حفاظت در برابر کاربران غیرمجاز در حال تلاش برای استفاده از نقاط انتهایی احراز هویت یا توکن دسترسی است.
در نهایت، لاگگیری هر صدور و استفاده توکن دسترسی، و تنظیم هشدارها برای ترکیبهای پرریسک (مانند توکن صادرشده از یک کشور و استفاده فوری از کشور دیگر) اقدامات خوبی برای انجام هستند. وقتی فعالیت مشکوک تشخیص داده شود، توکنهای implicated را لغو کنید، احراز هویت مجدد با MFA را اجبار کنید، و تحقیق را آغاز کنید.
مثالی از یک درخواست توکن مشکوک ممکن است مانند این به نظر برسد:
POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
User-Agent: python-requests/2.31.0
X-Forwarded-For: 198.51.100.23 grant_type=password&username=alice@example.com&password=********این درخواست به دلایل متعددی مشکوک است. عامل کاربر یک کلاینت اسکریپت عمومی به جای اپ رسمی است، آدرس IP X-Forwarded-For برای آن کاربر جدید است، و ممکن است یکی از بسیاری تلاشهای مشابه دیدهشده در توالی سریع باشد، که به عنوان پر کردن اعتبار شناخته میشود. مثالی از پاسخ دفاعی ممکن است علامتگذاری یا مسدود کردن تلاشهای مکرر، الزام چالش MFA برای حسابهای مشکوک، لاگ کردن رویداد برای بررسی توسط تیم امنیت سایبری شما، و، اگر توکنی از IP مشکوک استفاده شود، لغو فوری آن توکن و ارسال اطلاعرسانی به کاربر باشد.
نقاط انتهایی آپلود فایل و بلع محتوا
نقاط انتهایی آپلود فایل و بلع محتوا مانند /upload، /import، یا وبهوکهایی که URLهای خارجی را میپذیرند، همه اهداف رایجی برای مهاجمان هستند. آنها اغلب برای قاچاق فایلهای مخرب مانند بدافزار یا شلهای وب سوءاستفاده میشوند، یا برای فریب سیستم به انجام درخواستهای سمت سرور به زیرساخت کنترلشده توسط مهاجم. اگر محتوای آپلودشده یا بلعشده به درستی مدیریت نشود، میتواند از آسیبپذیریهای در پردازش پاییندستی، مانند روتینهای deserialization ناامن یا تجزیهکنندههای تصویر با نقصهای شناختهشده سوءاستفاده کند.
استفاده نامناسب اغلب با الگوهای غیرعادی ظاهر میشود. چنین آپلودهایی ممکن است شامل انواع فایل یا پسوندهایی باشند که با آنچه سرویس معمولاً میپذیرد مطابقت ندارند، مانند فایلهای اجرایی جایی که فقط فایلهای تصویر انتظار میرود. افزایش ناگهانی آپلودها از یک حساب یا آدرس IP واحد نیز ممکن است کاوش خودکار را پیشنهاد کند. خطاها یا کرشها در خطوط لوله بلع نیز میتواند نشانهای از بارهای مفید بدشکلشده برای فعال کردن باگها باشد. وقتی وبهوکها یا بلع مبتنی بر URL پشتیبانی میشود، درخواستهای خروجی به دامنههای مشکوک یا قبلاً ناشناخته میتواند به مهاجمی که در حال تلاش برای جعل درخواست سمت سرور (SSRF) است اشاره کند.
دفاع از نقاط انتهایی آپلود فایل با اعتبارسنجی ورودی سختگیرانه شروع میشود. فقط انواع محتوا و پسوندهای فهرست سفید را بپذیرید، و بیتهای اجرایی را از فایلها قبل از ذخیره یا پردازش آنها حذف کنید. تمام بلع و تجزیه باید در محیطهای sandboxed یا ایزوله اتفاق بیفتد تا تجزیهکننده به خطر افتاده نتواند کل سیستم را به خطر بیندازد.
تشخیص بدافزار با استفاده از آنتیویروس یا اسکنرهای یادگیری ماشین میتواند لایه دفاعی دیگری اضافه کند. واکشیهای از راه دور از URLهای ارائهشده توسط کاربر باید به شدت محدود شود، با قوانین خروجی شبکه که دسترسی به سیستمهای داخلی حساس را جلوگیری میکنند. محدودیت نرخ آپلودها، لاگگیری تمام فعالیتهای بلع، و نظارت بر افزایش حجم یا الگوهای مشکوک همه دفاعهای رایج در برابر استفاده غیرمجاز از آپلود فایل هستند.
در اینجا مثالی از یک درخواست آپلود مشکوک آورده شده است:
POST /upload HTTP/1.1
Host: files.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
User-Agent: Mozilla/5.0
X-Forwarded-For: 203.0.113.55
------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="invoice.pdf.php"
Content-Type: application/x-php
<?php system($_GET['cmd']); ?>
------WebKitFormBoundary--این آپلود به دلایل متعددی مشکوک است. نام فایلی که آپلود میشود invoice.pdf.php است، که یک اسکریپت PHP است که خود را به عنوان PDF جا زده است. نوع محتوا نیز با پسوند ادعایی مطابقت ندارد، و بار مفید شامل یک شل وب است. اگر چنین فایلی ذخیره و روی سرور نادرست پیکربندیشده اجرا شود، میتواند اجرای کد از راه دور به مهاجم بدهد. دفاعها باید عدم تطابق را تشخیص دهند، آپلود را مسدود کنند، و تیمهای امنیتی را از تلاش هشدار دهند.
افکار نهایی در مورد فراخوانیهای API رایج در حملات امنیت سایبری
دفاع از APIها در برابر حملات سایبری به اندازه سایر زمینههای امنیت سایبری مستقیم نیست، جایی که اغلب امکان خرید راهحل آماده وجود دارد. در عوض، امنیت سایبری برای APIها جنبههای بیشتری دارد، زیرا نیازمند تمایز بین ترافیک معتبر و استفاده غیرمجاز است.
دانستن اینکه مهاجمان مخرب معمولاً از چه نوع فراخوانیهای API استفاده میکنند، بخش جداییناپذیری از دفاع از اکوسیستم API شماست، و به مدیران API و تیمهای امنیت سایبری ایدهای از آنچه باید مراقب باشند میدهد.
همانطور که میبینید، حفاظت از APIهای شما بیش از فقط چسباندن فراخوانیهای API به سیستم امنیتیتان نیاز دارد، زیرا سیستم هر کسی کمی متفاوت است. در عوض، اصول و استراتژیهای پوشش دادهشده در بالا میتوانند به هر سیستمی اعمال شوند، صرفنظر از ابزارهایی که استفاده میکنید.
