فراتر از OWASP Top 10: شناسایی Business Logic Flaws و Broken Object Level Authorization در API‌های مدرن

29 تیر 1405 admin تست نفوذ وب 2 بازدید ۰ دیدگاه

با گسترش API-Driven Architecture (معماری مبتنی بر API) در سرویس‌های مدرن مانند Microservices (ریزخدمات)، Mobile Backend و Cloud-Native Applications، سطح حمله برنامه‌ها به شکل قابل توجهی افزایش یافته است. بسیاری از چارچوب‌های امنیتی مانند OWASP Top 10 بر آسیب‌پذیری‌های رایج تمرکز دارند، اما در معماری‌های API مدرن، تهدیدهایی مانند Business Logic Flaws (نقص در منطق تجاری) و Broken Object Level Authorization – BOLA (نقص در کنترل دسترسی سطح شیء) نقش بسیار مهمی در حملات واقعی دارند.

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

Business Logic Flaws چیست؟

Business Logic Flaws به ضعف‌هایی در منطق عملیاتی برنامه اشاره دارد که به مهاجم اجازه می‌دهد فرآیندهای طراحی‌شده برای کاربران عادی را به شکلی غیرمنتظره دستکاری کند.

برخلاف آسیب‌پذیری‌های فنی مانند SQL Injection یا Cross-Site Scripting – XSS، این نوع نقص‌ها معمولاً ناشی از طراحی نادرست Workflow برنامه هستند.

مثال در API

فرض کنید یک API برای انتقال پول وجود دارد:

  • POST /api/transfer
  • {
  • "from_account": "123",
  • "to_account": "456",
  • "amount": 100
  • }

اگر سیستم بررسی نکند که کاربر واقعاً مالک حساب from_account است، مهاجم می‌تواند با تغییر پارامترها پول را از حساب دیگران منتقل کند.

نمونه‌های رایج Business Logic Flaws

دور زدن محدودیت‌های پرداخت

خرید محصول با قیمت منفی یا صفر

استفاده چندباره از کوپن تخفیف

دور زدن محدودیت تعداد درخواست

تغییر وضعیت سفارش بدون طی مراحل قانونی

Broken Object Level Authorization (BOLA)

تعریف

Broken Object Level Authorization یکی از مهم‌ترین آسیب‌پذیری‌های OWASP API Security Top 10 است. این مشکل زمانی رخ می‌دهد که API اجازه دسترسی به یک Object (شیء) مانند رکورد دیتابیس یا فایل را بدون بررسی مجوز کاربر بدهد.

در APIهای REST معمولاً اشیاء با Object ID در URL مشخص می‌شوند.

مثال:

GET /api/orders/10245

اگر سیستم فقط بررسی کند که کاربر احراز هویت شده است ولی مالک سفارش را بررسی نکند، مهاجم می‌تواند با تغییر شناسه‌ها به داده‌های دیگران دسترسی پیدا کند.

تفاوت BOLA با Broken Access Control

Broken Access Control مفهوم گسترده‌تری دارد و شامل انواع مختلف نقض کنترل دسترسی است.

BOLA به‌طور خاص به دسترسی غیرمجاز به Objectهای خاص در API اشاره دارد.

در APIها به دلیل استفاده گسترده از ID-based Access، این آسیب‌پذیری بسیار رایج است.

روش‌های شناسایی BOLA در تست نفوذ API

1. تحلیل Endpointها

در ابتدا باید تمام API Endpointها شناسایی شوند. این کار می‌تواند با ابزارهایی مانند:

Burp Suite

Postman

OWASP ZAP

انجام شود.

2. بررسی پارامترهای Object ID

پارامترهایی مانند:

  • user_id
  • order_id
  • account_id
  • document_id

باید بررسی شوند تا مشخص شود آیا تغییر آن‌ها باعث دسترسی غیرمجاز می‌شود یا خیر.

3. تست Horizontal Privilege Escalation

در این تست، مهاجم با حساب کاربری عادی تلاش می‌کند به داده‌های کاربران دیگر دسترسی پیدا کند.

4. تست Vertical Privilege Escalation

در این حالت کاربر عادی تلاش می‌کند به منابعی که مخصوص Admin Role (نقش مدیر) هستند دسترسی پیدا کند.

تکنیک‌های شناسایی Business Logic Flaws

تحلیل Workflow برنامه

برای شناسایی نقص‌های منطقی باید جریان کامل عملیات بررسی شود، برای مثال:

ثبت سفارش

پرداخت

تأیید سفارش

ارسال کالا

اگر امکان تغییر ترتیب مراحل وجود داشته باشد، احتمال وجود Business Logic Flaw بالا است.

تست Race Condition

در برخی APIها اگر چند درخواست همزمان ارسال شود، ممکن است محدودیت‌های منطقی دور زده شوند.

Manipulation پارامترها

تغییر مقادیر پارامترهایی مانند:

  • price
  • quantity
  • role
  • discount

می‌تواند منجر به رفتار غیرمنتظره شود.

ابزارهای رایج برای تست امنیت API

چند ابزار مهم در API Security Testing عبارت‌اند از:

  • Burp Suite برای تحلیل و دستکاری درخواست‌های API
  • Postman برای تست Endpointها
  • OWASP ZAP برای اسکن آسیب‌پذیری
  • Kiterunner برای کشف Endpointهای پنهان
  • ffuf برای fuzzing پارامترها

روش‌های جلوگیری از BOLA و Business Logic Flaws

کنترل دسترسی در سطح Object

سیستم باید بررسی کند که کاربر مجاز به دسترسی به شیء موردنظر است.

استفاده از Access Control Policy

استفاده از مدل‌هایی مانند:

  • Role-Based Access Control – RBAC
  • Attribute-Based Access Control – ABAC
  • اعتبارسنجی سمت سرور

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

استفاده از شناسه‌های غیرقابل حدس

به‌جای IDهای ترتیبی می‌توان از:

  • UUID
  • Random Identifier

استفاده کرد.

طراحی امن Workflow

مراحل مهم مانند پرداخت یا تغییر وضعیت باید در سمت سرور به‌صورت سخت‌گیرانه کنترل شوند.

جمع‌بندی

در معماری‌های مدرن مبتنی بر API، بسیاری از حملات موفق ناشی از آسیب‌پذیری‌هایی هستند که در چارچوب OWASP Top 10 به‌طور مستقیم دیده نمی‌شوند. Business Logic Flaws و Broken Object Level Authorization (BOLA) نمونه‌هایی از این ضعف‌ها هستند که می‌توانند منجر به دسترسی غیرمجاز به داده‌ها یا سوءاستفاده از منطق تجاری برنامه شوند.

شناسایی این آسیب‌پذیری‌ها نیازمند تحلیل عمیق رفتار برنامه، تست دستی API و درک دقیق Workflow سیستم است. پیاده‌سازی کنترل دسترسی مناسب، اعتبارسنجی دقیق داده‌ها و طراحی امن فرآیندهای تجاری می‌تواند نقش مهمی در جلوگیری از این نوع حملات داشته باشد.

نویسنده

admin

ثبت دیدگاه