در قسمت اول مقاله چک‌لیست امنیت API بر اساس OWASP API Security Top 10 ، با اهمیت ارزیابی امنیت API و تعدادی از مهم‌ترین ریسک‌ها از جملهBroken Object Level Authorization، Broken Authentication، کنترل سطح دسترسی به Propertyها و محدودسازی مصرف منابع آشنا شدیم. اما بررسی امنیت API فقط به احراز هویت و سطح دسترسی محدود نمی‌شود. در بسیاری از حملات، مهاجم از منطق کسب‌وکار، پیکربندی نادرست سرویس، APIهای قدیمی یا حتی سرویس‌های شخص ثالث سوءاستفاده می‌کند.
در این قسمت، ادامه چک‌لیست امنیت API را بررسی می‌کنیم و به ریسک‌هایی مانند Broken Function Level Authorization، سوءاستفاده از Business Flowهای حساس، SSRF ، Security Misconfiguration، مدیریت Inventory و امنیت APIهای Third-Party می‌پردازیم. در پایان نیز یک چک‌لیست عملی ارائه می‌شود که می‌تواند در ارزیابی امنیت APIهای سازمانی مورد استفاده قرار گیرد.
Server-Side Request Forgery یا SSRF
SSRF زمانی ایجاد می‌شود که API یک URL را از کاربر دریافت کرده و سرور بدون Validation مناسب به آن آدرس Request ارسال کند. در این وضعیت مهاجم ممکن است تلاش کند API را مجبور کند به منابع داخلی سازمان، سرویس‌های Cloud Metadata یا سیستم‌هایی که از اینترنت قابل دسترسی نیستند متصل شود.
موارد چک‌لیست:
- URL ورودی کاربر اعتبارسنجی شود.
- مقصدهای مجاز با Allowlist مشخص شوند.
- دسترسی سرور API به شبکه‌های داخلی محدود شود.
- Redirectها کنترل شوند.
- دسترسی به IPهای داخلی و Metadata Endpointها محدود شود.
SSRF در نسخه 2023 به‌عنوان API7 معرفی شده است.
Security Misconfiguration
یک API امن می‌تواند فقط به دلیل Configuration اشتباه آسیب‌پذیر شود.
نمونه‌های رایج عبارت‌اند از:
- فعال بودن Debug Mode
- نمایش Stack Trace
- تنظیم نادرست CORS
- سرویس‌های اضافی
- Credentialهای پیش‌فرض
- TLS ضعیف
- Security Headerهای نامناسب
بنابراین بخشی از چک‌لیست امنیت API باید مستقیماً به Hardening اختصاص داشته باشد. همچنین تنظیمات محیط Development نباید بدون بازبینی وارد Production شوند.
بیشتر بخوانید: بررسی پورتال API برای VMware Tanzu: کشف، مدیریت و مستندسازی APIهای داخلی به‌صورت یکپارچه
Improper Inventory Management
یکی از مشکلات مهم سازمان‌ها نداشتن Inventory کامل از APIهای فعال است. ممکن است نسخه جدید API منتشر شده باشد، اما نسخه قبلی همچنان روی اینترنت قابل دسترسی باشد.
برای مثال:
/api/v1/
/api/v2/
اگر v1 دیگر نگهداری نمی‌شود اما همچنان فعال باشد، مهاجم می‌تواند آسیب‌پذیری‌های آن را هدف قرار دهد.
چک کنید:
- آیا لیست کاملی از APIها وجود دارد؟
- Owner هر API مشخص است؟
- نسخه‌های قدیمی حذف شده‌اند؟
- APIهای Test و Development از اینترنت قابل دسترسی نیستند؟
- مستندات Swagger یا OpenAPI به‌روز هستند؟
OWASP این موضوع را با عنوان Improper Inventory Management در API9 قرار داده است.
Unsafe Consumption of APIs
سازمان‌ها معمولاً فقط APIهایی را که خودشان ارائه می‌کنند بررسی می‌کنند؛ در حالی که بسیاری از برنامه‌ها به APIهای شخص ثالث نیز متصل هستند. نباید فرض کرد چون یک API متعلق به سرویس معتبر است، داده‌های دریافتی از آن همیشه امن هستند. OWASP در نسخه 2023 دسته Unsafe Consumption of APIs را برای همین ریسک اضافه کرده است.
موارد مهم:
- Response سرویس‌های خارجی Validate شود.
- Timeout تعریف شود.
- Redirectهای خارجی کنترل شوند.
- داده‌های دریافتی Sanitization شوند.
- دسترسی APIهای ثالث محدود شود.
- Credential سرویس‌های خارجی در Source Code ذخیره نشود.
بیشتر بخوانید: بررسی تاثیر نقض امنیتی و اهمیت پالیسی در محافظت از API
چک‌لیست نهایی ارزیابی امنیت API
در یک ارزیابی عملی می‌توان این سؤال‌ها را به‌عنوان چک‌لیست اولیه در نظر گرفت:
- آیا Authentication استاندارد و امن است؟
- آیا Authorization در سطح Object بررسی می‌شود؟
- آیا دسترسی به Functionها بر اساس Role کنترل شده است؟
- آیا Propertyهای حساس محافظت می‌شوند؟
- آیا Rate Limiting فعال است؟
- آیا Business Flowهای حساس در برابر Automation محافظت می‌شوند؟
- آیا API در برابر SSRF کنترل دارد؟
- آیا CORS،TLS و تنظیمات امنیتی بررسی شده‌اند؟
- آیا Inventory کاملی از APIها و نسخه‌های آن‌ها وجود دارد؟
- آیا APIهای خارجی و Third-Party قابل اعتماد فرض نمی‌شوند؟
- آیا Log مناسب برای Authentication، Authorization و عملیات حساس تولید می‌شود؟
- آیاLogهای API به SIEM ارسال و مانیتور می‌شوند؟
آیا OWASP API Security Top 10 برای ارزیابی کامل کافی است؟
خیر. OWASP API Security Top 10 بیشتر یک Awareness Document و نقطه شروع برای شناسایی مهم‌ترین ریسک‌هاست و جایگزین Threat Modeling ،Penetration Testing ،Secure Coding ،Code Review یا ارزیابی ریسک اختصاصی سازمان نیست. خود OWASP نیز تأکید می‌کند که میزان ریسک واقعی هر API به محیط، کاربرد، صنعت و تأثیر آن بر کسب‌وکار بستگی دارد. بنابراین بهتر است چک‌لیست OWASP در کنار تست نفوذ، بررسی معماری، کنترل دسترسی، Secure SDLC و مانیتورینگ مستمر استفاده شود.
داشتن یک چک‌لیست امنیت API باعث می‌شود بررسی API از یک فعالیت موردی و پراکنده به یک فرآیند ساختاریافته تبدیل شود. OWASP API Security Top 10 چارچوب مناسبی برای شروع این ارزیابی فراهم می‌کند، زیرا علاوه بر Authentication و Configuration، موضوعاتی مانند Object-Level Authorization ،Business Logic ،Resource Consumption ،API Inventory و استفاده از سرویس‌های Third-Party را نیز پوشش می‌دهد. با این حال، امنیت API یک تست یک‌باره نیست. هر API جدید، نسخه جدید،Endpoint جدید یا تغییر در سطح دسترسی کاربران می‌تواند سطح حمله جدیدی ایجاد کند. بنابراین سازمان‌ها باید چک‌لیست امنیت API را بخشی از چرخه توسعه نرم‌افزار، DevSecOps و فرآیند Continuous Security Testing قرار دهند تا آسیب‌پذیری‌ها پیش از تبدیل شدن به یک رخداد امنیتی شناسایی و اصلاح شوند.
