🔓مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش اول)

🔓مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش اول)

مقدمه: OWASP چیه؟

اختصار Open Worldwide Application Security Project، یه پروژه‌ی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرم‌افزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها و استانداردهایی مثل OWASP Top 10 به توسعه‌دهنده‌ها، معماران و امنیت‌کارها کمک می‌کنه تا ریسک‌های امنیتی را بهتر بشناسن و کاهش بدن.

طی سال‌های اخیر، با افزایش وابستگی به APIها، OWASP نسخه‌ی تخصصی‌تر از Top 10 رو برای امنیت APIها منتشر کرده که آخرین نسخه‌اش مربوط به سال ۲۰۲۳ است.

1️⃣ تهدید API1: Broken Object Level Authorization

مجوزدهی ناقص در سطح آبجکت

اگر API به درستی بررسی نکنه که آیا کاربر مجاز به دسترسی به یک آبجکت خاص (مثل userId یا accountId) هست یا نه، مهاجم می‌تونه به داده‌های دیگران دسترسی پیدا کنه.

مثال:

GET /api/users/12345/profile

شاید کاربر توی UI فقط پروفایل خودش رو ببینه، ولی اگر از طریق API شناسه کاربر دیگه‌ای رو درخواست بده می‌تونه پروفایل اون کاربر رو هم ببینه. کافیه تا سیستم چک نکنه که آیا اجازه داره پروفایل کاربر 12345 رو ببینه یا نه، اطلاعات افشا می‌شه.

روش‌های جلوگیری:

- بررسی دقیق سطح دسترسی در لایه‌ی بک‌اند برای هر درخواست.

- استفاده از tokenهایی که به صورت داخلی با دسترسی محدود مدیریت می‌شن.

- عدم اعتماد به اطلاعات ارسال‌شده از سمت کلاینت.

2️⃣تهدید API2: Broken Authentication

احراز هویت ناقص

سیستم‌هایی که از احراز هویت ناامن یا ناقص استفاده می‌کنن ممکنه اجازه‌ی دسترسی غیرمجاز رو محیا کنن.

مثال:

- استفاده از توکن‌های قابل پیش‌بینی یا بدون انقضا.

- ارسال اطلاعات ورود در متن ساده (plaintext).

روش‌های جلوگیری:

- استفاده از استانداردهای امن مثل OAuth 2.0 و OpenID Connect.

- توکن‌های کوتاه‌مدت با امکان ابطال (revocation).

- فعال کردن MFA (احراز هویت چندمرحله‌ای).

3️⃣تهدید API3: Broken Object Property Level Authorization

مجوزدهی ناقص در سطح ویژگی آبجکت‌ها

حتی اگر کاربر مجاز به دسترسی به یک آبجکت باشه، ممکنه مجاز به دسترسی یا تغییر همه‌ی ویژگی‌های اون آبجکت نباشه (مثلاً تاریخ ایجاد اون آبجکت یا تغییر مقدار حقوق خودش یا نقش کاربری‌اش).

مثال:

یک کاربر معمولی بتونه فیلدی مثل isAdmin=true را در payload قرار بده و نقش ادمین بگیره.

روش‌های جلوگیری:

- اعتبارسنجی دقیق ورودی‌ها و فیلتر کردن فیلدهای حساس.

- استفاده از DTOها (Data Transfer Object) برای کنترل فیلدهایی که کاربر می‌تونه ببینه یا تغییر بده.

4️⃣تهدید API4: Unrestricted Resource Consumption

مصرف بدون محدودیت از منابع

اگر API اجازه‌ی مصرف نامحدود منابع رو فراهم کنه (مثل حافظه، CPU یا اتصالات)، ممکنه با حملاتی مثل DoS مواجه بشه.

مثال:

GET /api/messages?limit=1000000

روش‌های جلوگیری:

- محدود کردن تعداد درخواست‌ها (Rate limiting).

- اعمال محدودیت روی پارامترهایی مثل limit, offset.

- احراز هویت برای دسترسی به عملیات سنگین.

5️⃣تهدید API5: Broken Function Level Authorization

مجوزدهی ناقص در سطح عملکرد

اگر API بررسی نکنه که آیا کاربر مجاز به استفاده از یک تابع خاص (مثلاً حذف یا تغییر داده‌ها) هست یا نه، ممکنه کاربر بتونه کارهایی کنه که مثلا از طریق UI قادر نیست ولی API این امکان رو بهش می‌ده.

مثال:

یک کاربر معمولی بتونه از API ادمین استفاده کنه:

DELETE /api/users/12345

روش‌های جلوگیری:

- تعیین سطح دسترسی دقیق برای هر endpoint و method.

- استفاده از Role-Based Access Control (RBAC).

- عدم اعتماد به نقش ارسال‌شده از سمت کلاینت.

💬 نظر؟ سوال؟ مفید بود؟