📌 معرفی (Definition)
آسیبپذیری Broken Object Level Authorization (BOLA) یکی از رایجترین و در عین حال خطرناکترین مشکلات امنیتی در APIها است که توسط OWASP بهعنوان یکی از زیرمجموعههای مهم دستهی Broken Access Control معرفی شده است.
در واقع BOLA تقریباً همان مفهومی است که در برنامههای وب با نام IDOR (Insecure Direct Object Reference) شناخته میشود؛ با این تفاوت که OWASP در حوزه API Security از اصطلاح دقیقتر BOLA استفاده میکند، چون تمرکز آن روی کنترل دسترسی در سطح Object است.
❓ BOLA چیست؟
BOLA زمانی رخ میدهد که سرور هنگام دسترسی به یک Object (مثل کاربر، سفارش، فایل و …) بررسی نکند که آیا کاربر فعلی اجازه دسترسی به آن Object را دارد یا خیر.
در نتیجه مهاجم میتواند با تغییر شناسه یک Object، به دادهها یا عملیات کاربران دیگر دسترسی پیدا کند.
📍 مثال ساده
فرض کنید درخواست زیر اطلاعات کاربر فعلی را برمیگرداند:
GET /api/v1/user/222
اگر مهاجم مقدار شناسه را تغییر دهد:
GET /api/v1/user/223
و اطلاعات کاربر دیگری را دریافت کند، یعنی سیستم دچار BOLA است.
⚠️ نکته مهم
در اینجا مشکل از Authentication نیست، چون کاربر وارد سیستم شده است؛ مشکل در Authorization (مجوز دسترسی) است.
یعنی سرور بررسی نمیکند:
آیا کاربر فعلی اجازه دسترسی به Object شماره 223 را دارد یا نه؟
📌 تعریف نهایی
اگر مهاجم بتواند با تغییر شناسه یا مرجع یک Object در درخواست، به دادهها یا عملیات مربوط به سایر کاربران دسترسی پیدا کند، با آسیبپذیری BOLA / IDOR مواجه هستیم.
⚔️ Attack Vector (سطوح حمله)
برای وقوع BOLA، مهاجم باید بتواند Object Identifier را کنترل یا تغییر دهد.
بنابراین نقاط آسیبپذیر معمولاً شامل موارد زیر هستند:
- APIهایی که اطلاعات حساس کاربران را برمیگردانند
- APIهایی که عملیات حساس انجام میدهند
- هر پارامتر یا شناسهای که برای دسترسی به Object استفاده میشود
🧩 نمونه Object Identifierها
GET /api/v1/users/123
GET /api/v1/orders/456
GET /api/v1/invoices/789
GET /api/v1/files/abc123
در اینجا:
123456789abc123
همگی نقش Object Identifier دارند.
⚠️ نکته مهم
Object Identifier فقط عدد نیست. میتواند یکی از موارد زیر باشد:
- UUID
- Hash
- Token
- Slug
- یا هر مقدار قابل شناسایی دیگر
اگر مهاجم بتواند این مقدار را تغییر دهد و به Object دیگران دسترسی بگیرد، BOLA رخ داده است.
💥 Impact (تأثیرات)
BOLA میتواند یکی از شدیدترین آسیبپذیریهای API باشد، چون مستقیماً به دادههای کاربران مرتبط است.
پیامدهای رایج:
- دسترسی به اطلاعات حساس سایر کاربران
- مشاهده اطلاعات شخصی، مالی یا محرمانه
- ویرایش یا حذف دادههای دیگران
- انجام عملیات به نام کاربران دیگر
- افشای اسناد، فایلها، پیامها یا سفارشها
- نقض کامل حریم خصوصی
🚨 سناریوهای شدید
در برخی شرایط، BOLA میتواند منجر به:
- افشای توکنهای نشست
- دسترسی به لینکهای Reset Password
- سرقت اطلاعات احراز هویت
- و در نهایت Account Takeover (ATO)
شود.
📊 نکته مهم
شدت BOLA کاملاً وابسته به نوع Object و سطح دسترسی است؛ از یک افشای ساده اطلاعات تا کنترل کامل حساب کاربر.
🛠️ Mitigation (روشهای جلوگیری)
برای جلوگیری از BOLA باید کنترل دسترسی بهدرستی در سمت سرور پیادهسازی شود.
✔️ راهکارهای اصلی:
- بررسی مالکیت Object در هر درخواست
- بررسی مجوز کاربر برای هر عملیات (Read / Write / Delete)
- عدم اعتماد به دادههای ورودی کاربر
- پیادهسازی Authorization در سمت سرور (نه کلاینت)
- استفاده از اصل Least Privilege
- محدود کردن دسترسی کاربران فقط به دادههای خودشان
🔐 استفاده از UUID
استفاده از شناسههای غیرقابل حدس (مثل UUID) میتواند:
- احتمال Enumeration را کاهش دهد
اما ❗
⚠️ کافی نیست! حتی اگر شناسهها غیرقابل حدس باشند، اگر Authorization درست نباشد، مهاجم همچنان میتواند با داشتن شناسه به دادهها دسترسی پیدا کند.
🎯 نتیجه مهم
راهحل اصلی BOLA، کنترل دسترسی صحیح در سمت سرور است، نه مخفی کردن یا پیچیده کردن IDها.
🧾 Checklist (چکلیست تست BOLA)
1. شناسایی Object Identifier
بررسی پارامترهایی مثل:
- User ID
- Order ID
- File ID
- UUID
- Hash
- Slug
مثال:
GET /api/v1/users/123
2. شناسایی Endpointهای حساس
بررسی APIهایی که:
- اطلاعات نمایش میدهند
- اطلاعات تغییر میدهند
- حذف انجام میدهند
- عملیات مالی دارند
- فایل ارائه میدهند
3. تست دسترسی بین کاربران
با تغییر شناسه بررسی کنید:
- آیا اطلاعات دیگران قابل مشاهده است؟
- آیا امکان ویرایش وجود دارد؟
- آیا حذف ممکن است؟
- آیا عملیات حساس اجرا میشود؟
4. کشف شناسه کاربران دیگر
اگر ID قابل حدس نبود:
- بررسی URLها
- پاسخ APIها
- لینکهای اشتراکگذاری
- اعلانها و پیامها
- فایلهای عمومی
5. بررسی Authorization
برای هر درخواست بررسی کنید:
- آیا مالکیت Object بررسی میشود؟
- آیا نقش کاربر بررسی میشود؟
- آیا سطح دسترسی اعمال میشود؟