آسیب پذیری های منطقی در باگ بانتی

آسیب‌پذیری‌های منطقی (Business Logic Vulnerabilities): شکارچیِ نهان در دنیای باگ‌بانتی

در دنیای امنیت، ابزارهای اسکنر و خودکار برای پیدا کردن باگ‌های فنی (مانند SQLi یا XSS) عالی عمل می‌کنند، اما آسیب‌پذیری‌های منطقی نقطه‌ضعفِ این ابزارهاست. باگ منطقی یعنی «کاربر بتواند با استفاده از قابلیت‌های قانونی سایت، عملیاتی را انجام دهد که توسعه‌دهنده برای آن محدودیت یا سناریوی خاصی تعریف نکرده است.» برخلاف خطاهای فنی، اینجا کد مخربی تزریق نمی‌شود؛ بلکه «منطقِ کسب‌وکار» دور زده می‌شود.

دسته‌بندی آسیب‌پذیری‌های منطقی

۱. دور زدن محدودیت‌ها (Access Control/Restriction Bypass): این باگ زمانی رخ می‌دهد که یک قابلیتِ محدود (مثل تخفیف یا قیمت) از طریق تغییر پارامترها قابل دستکاری باشد. مهاجم با تغییر نوع درخواست (مثلاً از GET به POST) یا حذف برخی پارامترهای کنترل‌کننده، به منابعی دسترسی پیدا می‌کند که نباید برای او مجاز باشد. این رایج‌ترین نوع باگ منطقی در سبدهای خرید و سیستم‌های پرداخت است.

۲. دستکاری در روندِ جریان (Workflow Bypass): بسیاری از اپلیکیشن‌ها مراحل گام‌به‌گام دارند (مثل: تأیید ایمیل -> انتخاب محصول -> پرداخت). باگ‌های منطقی در جریان کار زمانی رخ می‌دهند که مهاجم بتواند یک گام را حذف کند یا ترتیب آن‌ها را تغییر دهد. مثلاً با پریدن مستقیم از «انتخاب محصول» به «صفحه تایید نهایی پرداخت»، ممکن است بدون پرداخت، کالا دریافت شود.

۳. تغییر در محاسبات (Price/Quantity Manipulation): این باگ قلب تپنده حملات باگ‌بانتی است که در آن مقادیر عددی مثل قیمت، تعداد کالا یا امتیازِ وفاداری در سمت کلاینت یا در حین ارسال درخواست دستکاری می‌شوند. مهاجم ممکن است مقدار کالا را منفی وارد کند (مثلاً منفی یک) تا مبلغ کل فاکتور به جای بدهکار کردن او، اعتبارش را افزایش دهد.

۴. نقض اعتماد (Trust Boundary Violations): زمانی که سایت بیش از حد به داده‌های ارسالی از سمت کاربر اعتماد می‌کند، این باگ رخ می‌دهد. برای مثال، اگر فیلد is_admin یا role در یک درخواست JSON توسط کلاینت ارسال شود و سرور بدون چک کردن هویت واقعی، آن را بپذیرد، مهاجم می‌تواند با تغییر این پارامتر به true سطح دسترسی خود را به مدیر سیستم ارتقا دهد.

۵. سوءاستفاده از سیستم‌های اطلاع‌رسانی (Notification/Token Abuse): بسیاری از سامانه‌ها از توکن‌های یک‌بار مصرف برای بازیابی رمز عبور یا دعوت‌نامه استفاده می‌کنند. باگ‌های این بخش شامل پیش‌بینی‌پذیری این توکن‌ها (Predictable Tokens) یا ارسال آن‌ها به ایمیلِ مهاجم به جای کاربر هدف است که منجر به حساب‌ربایی (Account Takeover) در ابعاد گسترده می‌شود.

کجاها آسیب‌پذیری منطقی پیدا کنیم؟

به دنبال فرآیندهایی باشید که در آن‌ها ارزش مالی، سطح دسترسی یا داده‌های حساس جابه‌جا می‌شوند. سیستم‌های پرداخت، درگاه‌های بانکی، بخشِ “کد تخفیف” (Coupon codes)، سیستم‌های دعوت از دوستان (Referral Systems)، و فرآیندهای ثبت‌نام که شامل تأیید هویت هستند، معدن این باگ‌ها محسوب می‌شوند.

پارامترها و اندپوینت‌های هدف

در بررسی‌ها، پارامترهای عددی مثل price, qty, amount, total, discount, id, user_id را زیر نظر بگیرید. همچنین به اندپوینت‌هایی که فعل‌های update, upgrade, verify, checkout, redeem دارند، دقت کنید. این‌ها نقاطی هستند که منطقِ پشتِ آن‌ها معمولاً توسط توسعه‌دهندگان به درستی تست نشده است.

پیلودهای منطقی (Logic Payloads)

در باگ‌های منطقی، «پیلود» یک کد خاص نیست، بلکه یک «تغییر مفهوم» است.

• تغییر اعداد: ۱۰۰۰ تومان را به ۰ یا ۱ تبدیل کنید.

• اعداد منفی: quantity=-1.

• تغییر نوع: اگر پارامتر عددی است، true یا null یا یک آرایه مثل {"qty": [1, 2]} را تست کنید.

• تغییر هدرها: استفاده از هدرهای X-Forwarded-For برای دور زدن محدودیت‌های جغرافیایی یا IP.

URLهای حساس

در URLها، به دنبال پارامترهای رشته‌ای بگردید که به نظر می‌رسد وضعیت (State) را تغییر می‌دهند. مثلاً .../api/v1/user/upgrade?plan=free را به plan=premium تغییر دهید. URLهایی که شامل کلمات confirm, action, process هستند، معمولاً نقاط ضعیف منطقی دارند.

چه سامانه‌هایی در خطرند؟

• فروشگاه‌های اینترنتی: به دلیل گردش مالی و پیچیدگی سبد خرید.

• پلتفرم‌های SaaS: به دلیل سیستم‌های اشتراک و سطوح دسترسی (Role-based).

• اپلیکیشن‌های مالی و کیف پول: به دلیل انتقال و تبدیل اعتبار.

• سرویس‌های اشتراکی: به دلیل کدهای تخفیف و دعوت‌نامه.

۳ نکته کلیدی که هر شکارچی باید بداند:

۱. فکر کنید مثل یک کاربر مخرب، نه یک هکر: نپرسید «کجا را می‌توانم کرش کنم؟»، بپرسید «چطور می‌توانم از این سیستم پولی بدزدم یا خدمات رایگان بگیرم؟»

۲. مستندسازی دقیق: برای گزارش باگ‌های منطقی، باید دقیقا (Step-by-Step) نشان دهید که چه کاری انجام دادید. ویدیوهای Proof of Concept (PoC) برای این باگ‌ها حیاتی هستند چون مدیران امنیت معمولاً تا وقتی خودشان نبینند، متوجه عمق فاجعه نمی‌شوند.

۳. تست هم‌زمانی (Race Condition): همیشه بررسی کنید که اگر دو درخواست (مثلاً برداشت از کیف پول) را هم‌زمان بفرستید، سیستم چگونه رفتار می‌کند. این یک کلاس خاص از باگ‌های منطقی است که بسیار پولساز است.

سخن پایانی:

باگ‌های منطقی بهترین راه برای درک عمقِ بیزنسِ یک شرکت هستند. هرچه بیشتر وقت بگذارید تا بفهمید یک سیستم چطور «پول» یا «دسترسی» را مدیریت می‌کند، شانس بیشتری برای کشف باگ‌های منطقی و دریافت پاداش‌های کلان در باگ‌بانتی خواهید داشت.

برای تست امنیت سایت به ایدی @itman30 در بله پیام بدید