Business Logic Vulnerability چیست؟ بررسی آسیب‌پذیری منطق تجاری در وب‌سایت‌ها

Business Logic Vulnerability یا «آسیب‌پذیری منطق تجاری» زمانی ایجاد می‌شود که یک وب‌سایت یا نرم‌افزار از نظر فنی درست کار کند، اما قوانین واقعی کسب‌وکار را به‌درستی enforce نکند. در چنین شرایطی کاربر ممکن است بدون SQL Injection، XSS یا Payload خاص، از قابلیت‌های عادی سایت به ترتیبی استفاده کند که توسعه‌دهنده انتظار نداشته است؛ برای مثال مرحله‌ای الزامی را دور بزند، یک مزیت را بیش از تعداد مجاز دریافت کند، عملیاتی را در وضعیت نامعتبر انجام دهد یا دو Request هم‌زمان باعث ثبت نتیجه‌ای شوند که از نظر کسب‌وکار نباید امکان‌پذیر باشد.

مهم‌ترین راه جلوگیری از Business Logic Vulnerability این است که قوانین کسب‌وکار به‌صورت صریح تعریف و در سمت Server enforce شوند. Workflowها باید State Machine مشخص داشته باشند، قیمت و مالکیت و Permission از Server تعیین شوند، عملیات حساس Atomic و Idempotent طراحی شوند، محدودیت استفاده از قابلیت‌ها در Backend اعمال شود و تیم امنیت هنگام Threat Modeling فقط نپرسد «مهاجم چگونه Code را می‌شکند؟»، بلکه بپرسد «یک کاربر متقلب چگونه از قابلیت کاملاً سالم سیستم برخلاف هدف کسب‌وکار استفاده می‌کند؟»

Business Logic Vulnerability چیست؟

بسیاری از آسیب‌پذیری‌های وب را می‌توان با یک الگوی فنی مشخص توضیح داد.

در SQL Injection، ورودی غیرقابل‌اعتماد وارد Query می‌شود.

در XSS، داده کنترل‌شده توسط مهاجم در Context مرورگر به‌شکل ناامن قرار می‌گیرد.

در Path Traversal، User Input روی مسیر فایل اثر می‌گذارد.

اما Business Logic Vulnerability الزاماً چنین Signature مشخصی ندارد.

ممکن است تمام Inputها Validate شده باشند.

Queryها Parameterized باشند.

Outputها Encode شده باشند.

CSRF Protection نیز وجود داشته باشد.

با این حال فرایند خرید، پرداخت، رزرو یا اعمال تخفیف هنوز از نظر منطقی آسیب‌پذیر باشد.

OWASP Business Logic Security Cheat Sheet این مسئله را به‌صورت تفاوت میان «آنچه Developer به سیستم گفته انجام دهد» و «آنچه کسب‌وکار واقعاً انتظار دارد» توضیح می‌دهد. Code ممکن است دقیقاً همان چیزی را اجرا کند که نوشته شده، اما Requirement امنیتی یا Business Rule ناقص تعریف شده باشد.

فرض کنید فروشگاه قانونی دارد:

هر کد تخفیف فقط یک بار برای هر سفارش قابل استفاده است.

اگر Frontend بعد از یک بار استفاده دکمه اعمال تخفیف را غیرفعال کند ولی Backend بتواند همان عملیات را دوباره انجام دهد، سیستم از نظر UI درست به نظر می‌رسد اما Business Rule واقعی enforce نشده است.

این یک تفاوت بنیادی با بسیاری از Vulnerabilityهای سنتی دارد.

در اینجا مهاجم لزوماً Syntax یا Parser را نمی‌شکند.

او «فرضیات برنامه» را می‌شکند.

منطق تجاری یا Business Logic دقیقاً چیست؟

Business Logic مجموعه قواعدی است که تعیین می‌کند یک Application در دنیای واقعی چگونه باید رفتار کند.

برای یک فروشگاه اینترنتی، قوانین منطق تجاری می‌توانند شامل مواردی مانند این باشند:

چه کسی اجازه خرید دارد؟

قیمت نهایی چگونه محاسبه می‌شود؟

چه زمانی Discount معتبر است؟

کاربر چند بار می‌تواند از یک Coupon استفاده کند؟

آیا محصول موجود است؟

در چه زمانی موجودی باید کاهش پیدا کند؟

Refund در چه شرایطی مجاز است؟

سفارش بعد از ارسال می‌تواند لغو شود یا خیر؟

برای یک بانک، Business Ruleها متفاوت‌اند.

مثلاً:

Transfer باید از Account متعلق به همان User انجام شود.

Transfer بزرگ نیازمند Authorization اضافه است.

مبلغ برداشت نمی‌تواند بیشتر از موجودی قابل استفاده باشد.

یک Transaction تأییدشده نباید دوباره اجرا شود.

در یک سایت رزرو نیز قواعد ممکن است شامل ظرفیت، تاریخ، مالکیت Reservation، محدودیت تعداد رزرو و وضعیت پرداخت باشند.

در نتیجه Business Logic کاملاً Domain-Specific است.

به همین دلیل Scanner نمی‌تواند صرفاً با داشتن یک Pattern ثابت تمام Business Logic Vulnerabilityها را کشف کند.

چرا آسیب‌پذیری‌های منطق تجاری با باگ‌های عادی فرق دارند؟

Business Logic Bug می‌تواند در Code کاملاً Valid وجود داشته باشد.

برای مثال فرض کنید Backend چنین قانونی دارد:

اگر سفارش وجود دارد، اجازه لغو بده.

این کد از نظر Syntax و Runtime مشکلی ندارد.

اما Requirement واقعی شاید این باشد:

سفارش باید متعلق به User فعلی باشد،
هنوز ارسال نشده باشد،
Refund دیگری برای آن ثبت نشده باشد،
و وضعیت آن در یکی از Stateهای قابل لغو قرار داشته باشد.

فاصله بین این دو تعریف، همان جایی است که Business Logic Vulnerability شکل می‌گیرد.

OWASP WSTG تأکید می‌کند که تست منطق تجاری به شناخت کامل Business Process نیاز دارد و بسیاری از این مشکلات به‌راحتی با Vulnerability Scannerهای معمول قابل کشف نیستند. Tester باید Misuse Caseها، Sequenceها و حالت‌های غیرعادی را بررسی کند.

Business Logic Vulnerability چگونه ایجاد می‌شود؟

معمولاً یک علت منفرد وجود ندارد.

در اغلب موارد چند فرض اشتباه در کنار یکدیگر قرار می‌گیرند.

یکی از رایج‌ترین فرض‌ها این است:

کاربر همان مسیری را طی می‌کند که UI طراحی کرده است.

اما User کنترل HTTP Client خود را دارد.

او مجبور نیست حتماً دکمه‌ها را به ترتیب بزند.

می‌تواند Requestهایی را که Browser ارسال می‌کند مستقیماً ایجاد، تکرار یا در ترتیب متفاوت ارسال کند.

به همین دلیل Frontend بخشی از UX است، نه Boundary امنیتی.

اعتماد به ترتیب صفحات

فرض کنید فرایند خرید شامل چهار مرحله باشد:

Cart
 ↓
Address
 ↓
Payment
 ↓
Order Confirmation

Developer ممکن است فرض کند User فقط از Cart به Address و سپس Payment می‌رود.

اما امنیت باید در Backend تضمین کند که رسیدن به مرحله آخر فقط زمانی ممکن است که تمام Preconditionهای لازم واقعاً برقرار باشند.

OWASP این مسئله را در تست Circumvention of Work Flows مطرح می‌کند و می‌گوید Application باید اطمینان حاصل کند مراحل لازم در ترتیب درست انجام شده‌اند؛ اگر Workflow ناقص رها شود، Actionهای وابسته نیز باید Cancel یا Rollback شوند.

دور زدن مراحل Workflow

یکی از شناخته‌شده‌ترین Business Logic Vulnerabilityها زمانی رخ می‌دهد که User بتواند مرحله‌ای ضروری را Skip کند.

فرض کنید ثبت حساب چنین Workflowای دارد:

Create Account
      ↓
Email Verification
      ↓
Profile Completion
      ↓
Account Activation

اگر Backend Endpoint نهایی فقط بررسی کند که Account وجود دارد و بررسی نکند Email Verification واقعاً تکمیل شده، UI هرچقدر هم مرحله Verification را اجباری نشان دهد کافی نیست.

این ضعف از نظر CWE می‌تواند در شرایط مناسب با CWE-841 یعنی Improper Enforcement of Behavioral Workflow مرتبط باشد. MITRE این ضعف را حالتی تعریف می‌کند که Product دارای چند رفتار متوالی است ولی تضمین نمی‌کند Actor آنها را در Sequence موردنیاز انجام دهد.

انجام مراحل خارج از ترتیب

مشکل همیشه Skip کردن نیست.

گاهی همان مراحل انجام می‌شوند اما در ترتیب نامعتبر.

مثلاً یک Transaction ممکن است به‌صورت طراحی‌شده چنین باشد:

Create
 ↓
Validate
 ↓
Authorize
 ↓
Execute

اگر Endpoint Execute بدون بررسی State فعلی Transaction قابل فراخوانی باشد، User ممکن است از مسیر مورد انتظار خارج شود.

State نباید از URL یا صفحه‌ای که User روی آن قرار دارد استنباط شود.

Server باید خودش State واقعی Workflow را ذخیره کند.

اعتماد به داده‌های سمت Client

یکی از مهم‌ترین ریشه‌های Business Logic Vulnerability اعتماد به داده‌ای است که باید Server آن را محاسبه کند.

فرض کنید Browser هنگام Checkout چنین داده‌ای ارسال کند:

{
  "product_id": 50,
  "quantity": 2,
  "unit_price": 300
}

Application ممکن است واقعاً به product_id و quantity نیاز داشته باشد.

اما unit_price باید از Server-side Product Catalog به دست آید.

اگر Price ارسال‌شده توسط Client مبنای Charge قرار گیرد، Business Rule مهمی شکسته شده است:

قیمت، حقیقتی Server-Side است؛
نه ادعایی Client-Side.

OWASP Business Logic Security Cheat Sheet توصیه می‌کند مقادیر امنیتی مانند Price، Ownership، Identity و Permission از منابع Server-Side مشتق شوند و Client State صرفاً Input در نظر گرفته شود.

اعتماد به Hidden Field

Hidden Input نیز Trusted نیست.

مثلاً:

<input type="hidden" name="plan" value="basic">

فقط به این دلیل که User مقدار را در UI نمی‌بیند نمی‌توان Backend را از Validation معاف کرد.

Hidden Field، Disabled Input، JavaScript Variable، Mobile App Parameter و هر داده‌ای که از Client می‌آید قابل تغییر است.

Business Rule باید در Backend اعمال شود.

محدودیت تعداد استفاده از یک قابلیت

برخی Featureها فقط تعداد مشخصی بار باید قابل استفاده باشند.

برای مثال:

یک Coupon یک بار،

یک Trial یک بار،

سه Download در ماه،

یک Referral Reward برای هر User معتبر،

یک Vote برای هر Account،

یک درخواست Reset در بازه زمانی مشخص.

اگر Backend این Limit را enforce نکند، Business Logic Vulnerability ایجاد می‌شود.

OWASP WSTG بخش مستقلی برای تست «تعداد دفعات استفاده از Function» دارد و تأکید می‌کند Application باید خودش محدودیت استفاده از Feature را enforce کند؛ برای مثال Discount نباید بیش از دفعات تعیین‌شده اعمال شود یا Subscription Limit نباید قابل دور زدن باشد.

تفاوت Rate Limit با Business Limit

این دو مفهوم یکسان نیستند.

Rate Limit می‌گوید:

حداکثر 10 Request در دقیقه.

Business Limit ممکن است بگوید:

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

ممکن است Rate Limit کاملاً صحیح باشد اما User هر ده دقیقه یک بار Benefit جدید دریافت کند و در نهایت Business Rule را دور بزند.

بنابراین Feature-Level Limit و Network/API Rate Limit باید جداگانه طراحی شوند.

آسیب‌پذیری در سیستم‌های تخفیف

Discount Systemها نمونه کلاسیک Business Logic هستند.

قوانین ممکن است پیچیده باشند:

Coupon A فقط برای User جدید است.

Coupon B فقط روی Category مشخص اعمال می‌شود.

دو Coupon نباید هم‌زمان استفاده شوند.

Discount کل نباید از مبلغ سفارش بیشتر شود.

Coupon بعد از Refund نباید دوباره Benefit ایجاد کند.

یک Promotion ممکن است Expiration Time داشته باشد.

هر یک از این موارد یک Invariant است.

اگر یکی از آنها فقط در UI enforce شود یا در یکی از چند Endpoint بررسی نشود، امکان سوءاستفاده منطقی ایجاد می‌شود.

راهکار امن این نیست که مجموعه‌ای از Inputهای «مشکوک» را Block کنیم.

باید Business Ruleهای قابل قبول را دقیق تعریف و enforce کنیم.

قیمت منفی، صفر و مقادیر غیرمنطقی

Validation فقط درباره Data Type نیست.

ممکن است quantity از نوع Integer باشد اما مقدار آن از نظر Business غیرممکن باشد.

به همین دلیل باید میان Syntax Validation و Semantic Validation تفاوت قائل شد.

مثلاً:

quantity باید Integer باشد.

یک Rule فنی است.

اما:

quantity باید بین 1 و حداکثر موجودی قابل فروش باشد.

Business Validation است.

OWASP Top 10:2025 در A06 Insecure Design توصیه می‌کند Plausibility Check در لایه‌های مختلف Application اجرا شود؛ یعنی سیستم علاوه بر معتبر بودن فرمت داده، منطقی بودن آن نسبت به Domain را نیز بررسی کند.

Business Logic Vulnerability در پرداخت

Payment Flow یکی از حساس‌ترین Workflowهای سایت است.

یک Order ممکن است Stateهای زیر داشته باشد:

CREATED
  ↓
AWAITING_PAYMENT
  ↓
PAID
  ↓
PROCESSING
  ↓
SHIPPED

نباید Client بتواند خودش Status را به PAID تغییر دهد.

همچنین Redirect شدن User از Payment Gateway به سایت به‌تنهایی نباید دلیل پرداخت موفق باشد.

Server باید نتیجه Transaction را از Source معتبر بررسی کند.

مبلغ و Currency نیز باید با سفارش اصلی مطابقت داشته باشند.

یک Payment ID نباید بتواند Order دیگری را Paid کند.

Callback تکراری نباید Order یا Credit را چند بار ثبت کند.

این موارد Business Rule هستند.

Authorization تراکنش

برای عملیات بسیار حساس، Authentication معمولی ممکن است کافی نباشد.

مثلاً انتقال وجه می‌تواند نیازمند Transaction Authorization باشد.

OWASP Transaction Authorization Cheat Sheet توصیه می‌کند Authorization عملیات کاملاً در Server enforce شود و State Transitionهای Transaction در ترتیب موردنظر کنترل شوند. تغییر اطلاعات مهم Transaction باید Authorization قبلی را نامعتبر کند یا Process را از ابتدا آغاز کند.

اصل مهم این است:

User نباید یک Transaction را برای داده A تأیید کند و سپس داده Transaction به B تغییر کند درحالی‌که Authorization اولیه همچنان معتبر باقی مانده است.

Race Condition و Business Logic

برخی Business Logic Vulnerabilityها فقط با Requestهای هم‌زمان ظاهر می‌شوند.

فرض کنید User دقیقاً 100 واحد اعتبار دارد.

دو Request خرید تقریباً هم‌زمان ارسال می‌شوند.

هر Request ابتدا می‌خواند:

balance = 100

و هر دو نتیجه می‌گیرند خرید 80 واحدی مجاز است.

اگر عملیات:

Check Balance
 ↓
Charge
 ↓
Update Balance

Atomic نباشد، هر دو Transaction ممکن است موفق شوند.

این مشکل فقط یک Performance Issue نیست.

Business Invariant:

موجودی هرگز نباید منفی شود

شکسته شده است.

OWASP Business Logic Security Cheat Sheet توصیه می‌کند Concurrency را بخشی از Threat Model بدانیم و عملیات Check-Then-Act را با Transaction، Lock یا Conditional Update به‌صورت Atomic طراحی کنیم.

Atomicity چیست؟

Atomic Operation یعنی یک Business Action حساس یا کاملاً انجام شود یا اصلاً انجام نشود.

فرض کنید خرید باید:

موجودی را کاهش دهد،

Payment Record بسازد،

Order ایجاد کند،

و Coupon را مصرف‌شده علامت بزند.

اگر دو مرحله اول موفق شوند و مرحله سوم Fail شود، سیستم ممکن است وارد State ناسازگار شود.

Database Transaction، Idempotency، Retry Policy و Rollback Strategy باید با Business Rule هماهنگ باشند.

Idempotency چیست و چرا برای Business Logic مهم است؟

یک Operation Idempotent به شکلی طراحی می‌شود که اجرای چندباره همان Request نتیجه ناخواسته چندباره ایجاد نکند.

فرض کنید Client به‌دلیل Timeout مطمئن نیست Payment ثبت شده یا نه و Request را Retry می‌کند.

بدون کنترل مناسب ممکن است:

دو Order ساخته شود،

دو Charge ثبت شود،

دو Credit داده شود.

برای عملیات Non-Idempotent حساس، Idempotency Key می‌تواند کمک کند Server Request تکراری را تشخیص دهد و همان نتیجه قبلی را برگرداند، نه اینکه عملیات را دوباره انجام دهد.

این کنترل به‌خصوص برای Payment، Order Creation، Transfer و Reward اهمیت دارد.

Reservation و موجودی

سیستم رزرو یکی دیگر از محل‌های رایج Business Logic Abuse است.

Rule ممکن است بگوید:

یک Seat فقط یک بار قابل رزرو است.

Reservation بدون پرداخت فقط ده دقیقه معتبر است.

هر User حداکثر سه Slot فعال دارد.

ظرفیت کل باید رعایت شود.

اگر Reservation موقت منابع واقعی را بدون محدودیت Lock کند، یک User می‌تواند Availability را برای Userهای واقعی کاهش دهد.

OWASP API Security Top 10:2023 این مفهوم را در API6:2023 یعنی Unrestricted Access to Sensitive Business Flows مطرح می‌کند. Flowهایی مانند خرید، ارسال Comment و Reservation اگر محدودیت مناسب نداشته باشند ممکن است با استفاده بیش از حد به خود کسب‌وکار آسیب بزنند.

Business Logic Abuse و Automation

یک Feature ممکن است در استفاده انسانی کاملاً منطقی باشد اما با Automation خطرناک شود.

مثلاً یک سایت Ticketing فرض می‌کند هر انسان در هر دقیقه فقط چند Action انجام می‌دهد.

اما Bot می‌تواند هزاران Request ایجاد کند.

این مسئله لزوماً Authentication Failure نیست.

User ممکن است Account معتبر داشته باشد.

Endpoint نیز دقیقاً همان کاری را انجام دهد که طراحی شده است.

مشکل این است که Business Requirement مشخص نکرده Feature با چه Scale و Frequency مجاز است.

OWASP API6:2023 دقیقاً روی همین موضوع تمرکز دارد: Business Flow حساس اگر برای Access بیش از حد یا Automation محافظت نشده باشد، می‌تواند به ضرر کسب‌وکار منجر شود.

Referral و سیستم پاداش

سیستم Referral، Cashback، Loyalty Point و Bonus از Featureهای بسیار مستعد Business Logic Abuse هستند.

Business Ruleها باید مشخص کنند:

Referral واقعی چیست؟

آیا دو Account مرتبط می‌توانند یکدیگر را Referral کنند؟

Reward چه زمانی Final می‌شود؟

اگر Transaction Refund شد چه اتفاقی می‌افتد؟

آیا Reward Pending باید قابل خرج باشد؟

User چند بار می‌تواند Benefit دریافت کند؟

اگر این Rules فقط در سطح UI تعریف شوند، Abuse امکان‌پذیر است.

Refund Logic

Refund باید یک State Machine باشد.

برای مثال:

PAID
 ↓
REFUND_REQUESTED
 ↓
APPROVED
 ↓
REFUNDED

یک Order نباید دو بار Refund شود.

Refund نباید بیش از مبلغ Paid باشد.

Item Refundشده نباید دوباره بدون Rule مشخص Reward تولید کند.

Refund و Coupon و Loyalty Point باید با هم سازگار باشند.

مشکلات مالی زیادی نه از Injection بلکه از همین ناسازگاری بین Subsystemها ایجاد می‌شوند.

ثبت‌نام و Trial Abuse

یک SaaS ممکن است به هر User هفت روز Trial بدهد.

اما «هر User» باید تعریف شود.

آیا:

هر Email؟

هر Account؟

هر شخص؟

هر Payment Method؟

هر Organization؟

اگر Business Rule فقط روی Account ID اعمال شود، User ممکن است بتواند Accountهای متعددی بسازد.

راهکار لزوماً Block سخت‌گیرانه نیست.

باید Threat Model و Business Model تعیین کنند چه سطح Abuse قابل قبول است.

تغییر Email و Business Logic

تغییر Email در ظاهر Feature ساده‌ای است.

اما Rules زیادی دارد:

User باید Session معتبر داشته باشد.

ممکن است Reauthentication لازم باشد.

Email جدید نباید متعلق به Account دیگری باشد.

Email جدید باید Verify شود.

تا قبل از Verification، Email قبلی نباید فوراً بدون Recovery Path حذف شود.

Sessionهای حساس شاید نیاز به Refresh داشته باشند.

یک Feature ساده وقتی به State Transition تبدیل می‌شود پیچیدگی امنیتی زیادی پیدا می‌کند.

Password Reset و Workflow Logic

Password Reset نمونه مهم دیگری است.

فرایند امن باید میان:

درخواست Reset،

تولید Token،

تأیید Token،

انتخاب Password جدید،

Invalidation Token

رابطه مشخصی داشته باشد.

Token نباید پس از استفاده مجدداً معتبر باشد.

تغییر Account Data نباید Token را به Account دیگری مرتبط کند.

Reset Process باید در Server State ذخیره شود.

این موارد Business Workflow Security هستند، حتی اگر Token از نظر Cryptography قوی باشد.

نقش Fail Open در Business Logic

فرض کنید Service مربوط به بررسی Limit موقتاً unavailable شود.

Application دو انتخاب دارد:

اگر Check شکست خورد، اجازه عملیات بده.

یا:

اگر Check امنیتی تکمیل نشد، عملیات حساس را متوقف کن.

در عملیات حساس، Fail Open می‌تواند Business Rule را بی‌اثر کند.

OWASP Top 10:2025 دسته A10 Mishandling of Exceptional Conditions را برای خطاهای ناشی از شرایط غیرعادی، Fail Open و Logical Error معرفی کرده است. Business Logic باید برای Failure Stateها نیز Rule مشخص داشته باشد.

Business Logic Vulnerability و Access Control

Business Logic و Access Control همپوشانی زیادی دارند.

Authentication پاسخ می‌دهد:

این User چه کسی است؟

Authorization پاسخ می‌دهد:

این User اجازه انجام این Action را دارد؟

اما Business Authorization سؤال دقیق‌تری دارد:

آیا این User اجازه دارد
این Action را
روی این Object،
در این State،
با این مقدار،
در این زمان
انجام دهد؟

OWASP Authorization Cheat Sheet نیز تأکید می‌کند Authentication به‌تنهایی به معنی مجاز بودن تمام Actionها نیست. Authorization باید براساس Context واقعی Resource و Operation انجام شود.

Contextual Authorization چیست؟

فرض کنید Manager اجازه Approve کردن Expense را دارد.

Rule فقط این نیست:

role == manager

ممکن است Rule واقعی چنین باشد:

User مدیر است،
Expense متعلق به Team اوست،
Expense را خودش ایجاد نکرده،
Amount در Limit اختیار اوست،
Expense هنوز Pending است.

این Authorization وابسته به Business Context است.

Middleware عمومی Role Check ممکن است نتواند تمام این قواعد را اجرا کند.

بنابراین بخشی از Authorization باید نزدیک Business Operation قرار گیرد.

تفاوت Business Logic Vulnerability با IDOR

IDOR معمولاً زمانی مطرح می‌شود که User با تغییر Identifier به Object دیگری دسترسی پیدا می‌کند و Ownership به‌درستی بررسی نمی‌شود.

Business Logic Vulnerability دامنه وسیع‌تری دارد.

ممکن است اصلاً Resource متعلق به User دیگری وجود نداشته باشد.

مثلاً User روی Order خودش Actionی انجام دهد که در آن State مجاز نیست.

بنابراین IDOR می‌تواند یکی از مشکلات Business Context باشد، اما هر Business Logic Vulnerability یک IDOR نیست.

تفاوت Business Logic Vulnerability با SQL Injection

در SQL Injection مشکل Interpreter است.

User Data به Query Syntax تبدیل می‌شود.

در Business Logic Vulnerability ممکن است Database Query کاملاً Parameterized باشد و هیچ Injection رخ ندهد.

اما Application نتیجه Business اشتباه تولید کند.

این تفاوت نشان می‌دهد چرا Scannerهای Signature-Based برای Business Logic محدودیت دارند.

تفاوت Business Logic Vulnerability با XSS

XSS معمولاً دارای Context فنی مشخص در HTML، JavaScript یا DOM است.

Business Logic به Workflow و Rule مربوط است.

یک Checkout آسیب‌پذیر ممکن است هیچ Script Injection نداشته باشد اما همچنان اجازه Discount نامعتبر یا Workflow Bypass بدهد.

تفاوت Business Logic Vulnerability با Race Condition

Race Condition می‌تواند یکی از Root Causeهای Business Logic Violation باشد.

اما Business Logic Vulnerabilityهای زیادی بدون Concurrency رخ می‌دهند.

مثلاً:

Skip مرحله Verification،

استفاده بیش از حد Coupon،

تغییر Price،

استفاده از Feature در State نامعتبر.

Race Condition یک Pattern فنی مشخص‌تر است.

Business Logic Failure نتیجه شکستن Rule Domain است.

CWE مربوط به Business Logic Vulnerability چیست؟

این بخش نیازمند دقت است.

CWE-840 با عنوان Business Logic Errors یک Category است، نه یک Weakness قابل استفاده مستقیم برای نگاشت Vulnerability واقعی.

MITRE صراحتاً Usage آن را برای Vulnerability Mapping برابر PROHIBITED قرار داده است و توصیه می‌کند Root Cause دقیق شناسایی و CWE مناسب‌تر انتخاب شود.

برای مثال Workflow Bypass ممکن است با CWE-841 یعنی Improper Enforcement of Behavioral Workflow مرتبط باشد.

اگر Action باید فقط یک بار قابل اجرا باشد، CWE-837 یعنی Improper Enforcement of a Single, Unique Action می‌تواند مرتبط باشد.

اگر Ownership بررسی نشده، CWE دیگری مناسب خواهد بود.

بنابراین عبارت:

CWE-840 = تمام Business Logic Vulnerabilityها

بیان دقیقی نیست.

Business Logic در OWASP Top 10:2025

Business Logic Vulnerability به‌صورت یک عنوان مستقل در OWASP Top 10:2025 وجود ندارد.

اما OWASP آن را به‌طور واضح در A06:2025 Insecure Design پوشش می‌دهد.

OWASP در توضیح Insecure Design به نقص‌های Business Logic مانند تعریف نکردن State Changeهای ناخواسته یا غیرمنتظره اشاره می‌کند و Threat Modeling، Secure Design و تست Critical Flowها را از راهکارهای اصلی می‌داند.

این نکته مهم است.

Business Logic Vulnerability اغلب یک مشکل Design-Time است.

اگر Business Rule هرگز تعریف نشده باشد، Developer نمی‌تواند چیزی را enforce کند که وجود ندارد.

چرا Scannerها معمولاً Business Logic Vulnerability را پیدا نمی‌کنند؟

Scanner می‌تواند Patternهای زیادی را آزمایش کند.

مثلاً Characterهای SQL را وارد Input کند.

HTML را Reflect کند.

Header را بررسی کند.

Directory را Crawl کند.

اما چگونه Scanner بداند:

هر User فقط یک Bonus باید داشته باشد؟

Refund بعد از Shipping ممنوع است؟

Manager اجازه Approve کردن Request خودش را ندارد؟

Coupon A با Coupon B نباید ترکیب شود؟

Reservation بدون پرداخت فقط ده دقیقه معتبر است؟

این Knowledge داخل Business Domain قرار دارد.

MITRE نیز می‌گوید Business Logic Errorها برای Automated Analysis دشوارند چون عملیات معمولاً از نظر Code کاملاً Legitimate هستند و برای تشخیص Weakness به Domain-Specific Knowledge نیاز است.

آیا تست خودکار برای Business Logic بی‌فایده است؟

خیر.

تست خودکار بسیار مفید است؛ اما ابتدا Human باید Rule را تعریف کند.

پس از آن می‌توان Unit Test، Integration Test و Property-Based Test نوشت.

مثلاً Business Invariant:

RefundTotal <= PaidTotal

را می‌توان خودکار تست کرد.

یا:

Order SHIPPED cannot transition to CANCELLED

می‌تواند Regression Test داشته باشد.

بنابراین مشکل Automation این نیست که هیچ کاری نمی‌تواند انجام دهد.

مسئله این است که Tool نمی‌تواند Business Requirement ناشناخته را از خودش اختراع کند.

Business Invariant چیست؟

Invariant قانونی است که در تمام Stateهای معتبر سیستم باید برقرار باشد.

مثلاً:

Account Balance cannot become negative.

یا:

A coupon can only be redeemed once per eligible account.

یا:

A refunded order cannot generate another loyalty reward.

یا:

Only an owner can cancel an active reservation.

یکی از بهترین روش‌های Secure Design این است که این Invariantها قبل از Coding نوشته شوند.

برای هر Rule باید مشخص شود:

کدام Component آن را enforce می‌کند؟

در چه Transaction Boundary؟

در چه Database Constraint؟

با چه Test؟

State Machine در طراحی امن

برای Workflowهای چندمرحله‌ای، State Machine یکی از مؤثرترین الگوهاست.

فرض کنیم KYC دارای Stateهای زیر باشد:

NOT_STARTED
   ↓
SUBMITTED
   ↓
UNDER_REVIEW
   ↓
APPROVED

Transitionهای مجاز باید صریح باشند.

مثلاً:

Backend باید هر Transition را بررسی کند.

Frontend فقط State را نمایش می‌دهد.

OWASP Business Logic Security Cheat Sheet نیز توصیه می‌کند Workflowهای چندمرحله‌ای به State Machine صریح در Server تبدیل شوند و هر Transition نسبت به State فعلی Validate شود.

تست Business Logic از کجا شروع می‌شود؟

اول باید Application را از دید Business بفهمید.

نه فقط URLها را.

تیم تست باید بداند:

دارایی ارزشمند چیست؟

چه Featureهایی Money یا Credit جابه‌جا می‌کنند؟

چه Featureهایی Permission تغییر می‌دهند؟

چه Workflowهایی چندمرحله‌ای هستند؟

کدام Action محدودیت دفعات دارد؟

چه چیزی باید فقط یک بار اتفاق بیفتد؟

چه Stateهایی Terminal هستند؟

چه Ruleهایی میان چند Service مشترک‌اند؟

OWASP WSTG نیز تست Business Logic را وابسته به فهم Business Process و Rules می‌داند.

تست ترتیب Workflow

در محیط مجاز می‌توان بررسی کرد آیا Backend مراحل را مستقل Validate می‌کند.

هدف این نیست که Process واقعی مشتریان را مختل کنیم.

در Staging یک Workflow آزمایشی ساخته می‌شود.

سپس Sequenceهای مجاز و نامعتبر تست می‌شوند.

مثلاً:

Step 1 → Step 2 → Step 3

و:

Step 1 → Step 3

یا تکرار Step 2.

انتظار باید از قبل مشخص باشد.

تست Request خارج از UI

Backend نباید فرض کند Request فقط از Official Frontend می‌آید.

OWASP WSTG بخشی با عنوان Test Ability to Forge Requests دارد و توضیح می‌دهد مهاجم می‌تواند GUI را دور بزند و Requestهای GET/POST را مستقیماً با مقادیری بفرستد که UI اجازه تولید آنها را نمی‌دهد.

در تست دفاعی باید بررسی شود Backend خودش Rules را enforce می‌کند.

تست محدودیت‌ها

اگر Documentation می‌گوید:

حداکثر پنج Item،

یک Discount،

سه Download،

دو Reservation،

یک Reward،

همه این Rules باید در Server قابل تست باشند.

Boundary Test مهم است.

مثلاً اگر Limit برابر 3 است:

1، 2، 3 باید رفتار مجاز داشته باشند.

4 باید رفتار مشخص و امن داشته باشد.

همچنین اجرای Parallel باید بررسی شود تا Race Condition Limit را دور نزند.

تست Failure State

یکی از مهم‌ترین بخش‌هایی که اغلب فراموش می‌شود Failure است.

اگر Payment Provider Timeout شود چه؟

اگر Database Update دوم Fail شود چه؟

اگر Email Verification ارسال شود ولی State Update Fail کند چه؟

اگر Callback دوبار برسد چه؟

اگر Worker Job Retry شود چه؟

اگر User Browser را در میانه Workflow ببندد چه؟

Security فقط Happy Path نیست.

سیستم باید برای Partial Failure نیز State امن داشته باشد.

تست نقش‌ها

Business Rule ممکن است برای Roleهای مختلف متفاوت باشد.

مثلاً:

Customer می‌تواند Order خود را Cancel کند.

Support می‌تواند Cancel درخواست‌شده را بررسی کند.

Finance می‌تواند Refund انجام دهد.

Administrator می‌تواند Override کند.

اما Override نیز باید Audit Trail داشته باشد.

هر Role باید در هر State بررسی شود.

تست Cross-Channel

بسیاری از سیستم‌ها چند Interface دارند:

Web،

Mobile،

REST API،

Admin Panel،

Webhook،

Legacy API.

ممکن است Business Rule در Web جدید enforce شود ولی API قدیمی همان عملیات را بدون کنترل انجام دهد.

OWASP Business Logic Security Cheat Sheet توصیه می‌کند تمام Entry Pointهای یک Sensitive Operation شناسایی شوند و همان Business Ruleها روی همه آنها اعمال شوند.

چگونه از Business Logic Vulnerability جلوگیری کنیم؟

اولین قدم این است که Security را بخشی از Business Requirement بدانیم.

نگوییم:

User can use coupon.

Rule باید دقیق باشد:

Verified users can redeem coupon X once
on eligible products,
before expiration,
and coupon X cannot be combined with coupon Y.

هرچه Requirement مبهم‌تر باشد، Implementationهای متفاوت‌تری ایجاد می‌شوند.

قوانین را در Server enforce کنید

Frontend قابل اعتماد نیست.

Mobile App نیز قابل اعتماد نیست.

حتی Official Client قابل تغییر و Reverse Engineering است.

Backend باید منبع حقیقت باشد.

قیمت، Ownership، Role، Eligibility، Limit و State از Server-side Sources به دست آیند.

Security-Relevant Value را دوباره محاسبه کنید

برای Checkout:

Client می‌گوید چه Product و Quantity می‌خواهد.

Server محاسبه می‌کند:

Price،

Tax،

Discount،

Shipping،

Final Total.

برای Permission:

Client نمی‌گوید Role چیست.

Server آن را از Session/Token و Database به دست می‌آورد.

برای Ownership:

Client Object ID ارسال می‌کند.

Server بررسی می‌کند Object متعلق به چه Entity است.

این Pattern بسیاری از Business Logic Vulnerabilityها را کاهش می‌دهد.

State Machine صریح بسازید

State را در URL یا Frontend infer نکنید.

State در Server Storage نگهداری شود.

هر Action باید Transition مجاز را بررسی کند.

Transition نامعتبر باید رد شود.

همچنین State Change باید در صورت نیاز Atomic باشد.

عملیات مالی را Atomic کنید

برای Business Operationهای حساس از Database Transaction، Lock یا Conditional Update استفاده کنید.

مثلاً به‌جای:

Read balance
Check balance
Write new balance

می‌توان Operation را با Condition انجام داد که فقط اگر Balance کافی است Update موفق شود.

پیاده‌سازی دقیق به Database بستگی دارد، اما اصل این است:

Check و Change نباید Window ناامن ایجاد کنند.

Idempotency را برای Actionهای حساس در نظر بگیرید

در APIهای Payment یا Order، Request Retry یک اتفاق طبیعی است.

Server باید بتواند بفهمد Request همان عملیات قبلی است.

Idempotency Key باید به Business Operation صحیح Bind شود.

Key نباید اجازه دهد Data Transaction در Retry تغییر کند.

Business Limitها را در Database نیز enforce کنید

اگر Rule بسیار حساس است، تنها Application Check کافی نیست.

Database Constraint، Unique Index یا Transactional Condition می‌تواند لایه دفاع اضافه باشد.

مثلاً Rule:

یک Reward از نوع X برای هر Account

ممکن است بتواند با Unique Constraint تقویت شود.

این کار Race Condition را نیز کاهش می‌دهد.

Authorization را Contextual کنید

سؤال Security Check فقط این نباشد:

isAuthenticated?

یا:

role == admin?

بلکه:

آیا User فعلی،
روی این Object،
در این State،
در این زمان،
این Action را انجام می‌دهد؟

این رویکرد Business Context را وارد Authorization می‌کند.

Rate Limit را Feature-Aware طراحی کنید

Login Rate Limit کافی نیست.

Featureهایی مثل:

Coupon،

Referral،

Reservation،

Password Reset،

Voucher،

Comment،

Search،

Export

ممکن است Limit جداگانه نیاز داشته باشند.

Limit ممکن است بر اساس:

Account،

IP،

Device،

Resource،

Organization،

یا Combination

تعریف شود.

انتخاب باید براساس Threat Model کسب‌وکار باشد.

Automation را از ابتدا در Threat Model در نظر بگیرید

هر Actionی که یک انسان می‌تواند انجام دهد ممکن است Bot هزاران بار انجام دهد.

سؤال مهم:

اگر این Feature ده هزار بار در ساعت استفاده شود چه اتفاقی می‌افتد؟

آیا هزینه ایجاد می‌کند؟

Inventory را قفل می‌کند؟

Notification ارسال می‌کند؟

SMS پولی می‌فرستد؟

Reward تولید می‌کند؟

Spam ایجاد می‌کند؟

OWASP API6:2023 توصیه می‌کند Sensitive Business Flowها شناسایی و برای Abuse خودکار مکانیزم مناسب انتخاب شود.

Rollback Strategy داشته باشید

در Workflow چندمرحله‌ای، Failure نباید State نصفه رها کند.

اگر عملیات 4 مرحله دارد و مرحله 3 Fail شد، مشخص کنید:

آیا 1 و 2 Rollback می‌شوند؟

آیا Job Retry می‌شود؟

آیا State به FAILED می‌رود؟

آیا User می‌تواند دوباره تلاش کند؟

بدون چنین طراحی‌ای Invalid State ایجاد می‌شود.

Logging و Monitoring مخصوص Business Logic

Security Log فقط برای Login Failure نیست.

Business Eventهای حساس نیز باید قابل Audit باشند.

مثلاً:

Coupon Redeemed،

Refund Created،

Permission Changed،

Reservation Cancelled،

Reward Issued،

Payout Requested.

Log باید Context کافی برای Reconstruction حادثه داشته باشد.

همچنین Alert باید روی Patternهای غیرعادی باشد.

مثلاً Userای که در چند دقیقه تعداد غیرمعمولی Reservation ایجاد می‌کند ممکن است از نظر HTTP کاملاً Requestهای معتبر ارسال کند؛ Detection باید Business-Aware باشد.

Threat Modeling مخصوص منطق تجاری

Threat Modeling نباید فقط Diagram شبکه باشد.

برای هر Feature بپرسید:

دارایی چیست؟

User چه Benefitی دریافت می‌کند؟

چگونه می‌تواند Benefit را بیش از حد بگیرد؟

چه Stepی ممکن است Skip شود؟

چه Actionی ممکن است Repeat شود؟

چه Dataای از Client نباید Trust شود؟

اگر Requestها هم‌زمان باشند چه می‌شود؟

اگر External Service Fail شود چه؟

اگر User عمداً خلاف فرضیات Product رفتار کند چه؟

OWASP Top 10:2025 در A06 Insecure Design، Threat Modeling برای Authentication، Access Control، Business Logic و Critical Flowها را از کنترل‌های اصلی پیشگیری معرفی می‌کند.

Business Logic Vulnerability در WordPress

WordPress Core یک CMS عمومی است، اما Pluginها و Themeها می‌توانند Business Workflowهای پیچیده بسازند.

مثلاً:

عضویت،

اشتراک،

رزرو،

فروش فایل،

Wallet،

Referral،

Coupon،

فرم تأیید،

Marketplace.

خطر اصلی اغلب در Custom Code و Plugin Logic ایجاد می‌شود.

یک AJAX Action ممکن است Nonce داشته باشد ولی Business Authorization ناقص باشد.

Nonce اثبات می‌کند Request احتمالاً از Session معتبر آمده است؛ اما لزوماً ثابت نمی‌کند User اجازه Business Action را دارد.

Business Logic در WooCommerce

WooCommerce نمونه‌ای واضح از سیستم Domain-Heavy است.

Order دارای State است.

Coupon Rule دارد.

Stock Management وجود دارد.

Payment Callback وجود دارد.

Refund و Tax و Shipping وجود دارند.

Plugin سفارشی که این Flowها را تغییر می‌دهد باید قواعد را دقیق رعایت کند.

برای مثال هنگام ساخت افزونه تخفیف نباید فقط Price نمایش‌داده‌شده در Cart تغییر کند؛ Server-side Order Total و Payment Amount باید از منبع هماهنگ محاسبه شوند.

همچنین Actionهای Order باید State فعلی را Validate کنند.

Nonce کافی نیست

یکی از سوءبرداشت‌های رایج WordPress این است که:

check_ajax_referer() موفق شد
پس Action امن است.

Nonce بیشتر برای CSRF Protection است.

هنوز باید بررسی شود:

User Authentication،

Capability،

Ownership،

Business State،

Limit،

و Input Validation.

CSRF Protection جایگزین Business Authorization نیست.

Business Logic در REST API وردپرس

در REST Endpoint سفارشی نیز permission_callback اهمیت دارد.

اما حتی Permission Callback عمومی مثل «User لاگین است» ممکن است کافی نباشد.

Endpoint باید بررسی کند آیا User روی Resource مشخص و در وضعیت فعلی اجازه Action دارد.

اشتباهات رایج توسعه‌دهندگان در منطق تجاری

یکی از بزرگ‌ترین اشتباهات این است که UI به‌عنوان Security Control در نظر گرفته شود.

اشتباه دیگر اعتماد به Hidden Field و JavaScript Validation است.

بعضی تیم‌ها نیز Limit را فقط با Rate Limiter پیاده می‌کنند درحالی‌که Business Limit متفاوت است.

برخی سیستم‌ها State را فقط از Page Flow استنباط می‌کنند و State Machine Server-Side ندارند.

گاهی Price، Discount یا Role از Client پذیرفته می‌شود.

در سیستم‌های مالی نیز اجرای Check و Update در دو Operation جدا باعث Race Condition می‌شود.

یکی دیگر از خطاها این است که Business Rule فقط روی Endpoint اصلی اعمال شود و نسخه API قدیمی یا Admin Endpoint همان Action را بدون Rule کامل انجام دهد.

چک‌لیست دفاعی جلوگیری از Business Logic Vulnerability

چگونه یک Business Logic Vulnerability را گزارش کنیم؟

گزارش نباید فقط بنویسد:

Business logic issue exists.

باید Business Rule مورد انتظار را مشخص کند.

مثلاً:

Rule:
هر Coupon باید حداکثر یک بار برای هر Account قابل استفاده باشد.

سپس رفتار واقعی بیان شود:

Observed Behavior:
Backend امکان ثبت چند Redemption مستقل را می‌پذیرد.

بعد Impact:

Impact:
User می‌تواند Benefit بیشتری از مقدار طراحی‌شده دریافت کند.

و در نهایت Root Cause و Remediation:

Root Cause:
Usage Limit فقط در Frontend کنترل شده است.

Remediation:
Limit را در Server و Transaction مربوطه enforce کنید
و در صورت مناسب بودن با Database Constraint تقویت کنید.

این گزارش برای Developer بسیار مفیدتر از برچسب کلی «Business Logic» است.

آیا Business Logic Vulnerability همیشه Critical است؟

خیر.

Severity کاملاً به Business Impact بستگی دارد.

اگر User بتواند یک Welcome Message را دو بار دریافت کند، احتمالاً Risk پایین است.

اگر همان ضعف باعث شود Transfer مالی دو بار انجام شود، موضوع بسیار جدی است.

برای Severity باید موارد زیر بررسی شوند:

ارزش Asset،

میزان Benefit،

تعداد Userهای قابل تأثیر،

نیاز یا عدم نیاز به Authentication،

قابلیت Automation،

مقیاس Abuse،

قابلیت تکرار،

اثر مالی،

اثر روی Integrity،

و Detection Difficulty.

Business Impact با Technical Impact فرق دارد

ممکن است هیچ Serverی Compromise نشود.

هیچ Shellی اجرا نشود.

هیچ Databaseای Dump نشود.

اما Business میلیون‌ها تومان ضرر کند.

مثلاً Bot موجودی محصول محدود را رزرو کند و User واقعی نتواند خرید انجام دهد.

OWASP API6 نیز اشاره می‌کند که Business Flow Abuse ممکن است Impact فنی سنتی زیادی نداشته باشد اما Business Impact قابل توجهی ایجاد کند.

این نکته در ارزیابی Severity بسیار مهم است.

Business Logic و Secure by Design

اصلاح Business Logic بعد از Production معمولاً سخت‌تر از Fix کردن یک Output Encoding ساده است.

چون ممکن است Database Schema، Workflow، API Contract و Product Requirement همگی نیاز به تغییر داشته باشند.

به همین دلیل Secure by Design اهمیت دارد.

OWASP Top 10:2025 بین Insecure Design و Insecure Implementation تفاوت قائل می‌شود.

یک Design امن ممکن است Bad Implementation داشته باشد.

اما اگر Design از ابتدا Control موردنیاز را تعریف نکرده باشد، اجرای بی‌نقص همان Design نیز امن نخواهد بود.

Abuse Case چیست؟

Use Case توضیح می‌دهد User عادی چه کاری انجام می‌دهد.

مثلاً:

User Coupon را اعمال می‌کند.

Abuse Case می‌پرسد:

اگر User Coupon را چند بار اعمال کند چه؟

اگر دو Coupon ناسازگار را ترکیب کند چه؟

اگر Coupon منقضی باشد ولی Request مستقیم ارسال شود چه؟

اگر Request هم‌زمان ارسال شود چه؟

اگر Coupon روی Order دیگری Replay شود چه؟

هدف Abuse Case فکر کردن از زاویه کاربر غیرهمکار است.

Misuse Case و تست امنیت

Misuse Case نیز سناریویی است که Feature در روشی غیر از هدف طراحی‌شده استفاده می‌شود.

OWASP WSTG Business Logic Testing را بسیار نزدیک به Functional Testing و Finite-State Testing می‌داند و توصیه می‌کند Tester Misuse Caseها را براساس Process کامل طراحی کند.

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

QA Business Requirement را می‌شناسد.

AppSec Abuse Patternها را می‌شناسد.

ترکیب این دو بسیار مؤثر است.

Business Logic در CI/CD چگونه تست شود؟

پس از تعریف Invariantها، تست خودکار ایجاد کنید.

مثلاً:

OrderTotal never becomes negative.

UsedCoupon cannot return to UNUSED
without an explicit administrative rollback.

A paid transaction cannot be executed twice.

A SHIPPED order cannot transition back to PENDING_PAYMENT.

این Testها در هر Deployment اجرا شوند.

Regression اهمیت زیادی دارد، زیرا Business Flow با اضافه شدن Feature جدید ممکن است ناخواسته شکسته شود.

Monitoring بعد از انتشار

Secure Design احتمال Abuse را کاهش می‌دهد اما Detection همچنان ضروری است.

Business Metricها می‌توانند Signal امنیتی باشند.

مثلاً:

نرخ غیرعادی Coupon Redemption،

Refund Rate غیرمعمول،

Account Creation زیاد،

Reservation Cancellation بالا،

Reward Issuance Spike،

Payment Retry غیرمعمول.

Security Monitoring باید با Business Analytics ارتباط داشته باشد.

گاهی بهترین Detector یک SIEM Rule سنتی نیست، بلکه یک Business KPI غیرعادی است.

اگر Business Logic Vulnerability پیدا شد چه کنیم؟

اول Rule واقعی را با Product Owner مشخص کنید.

گاهی رفتار عجیب از دید Tester ممکن است واقعاً Feature موردنظر کسب‌وکار باشد.

پس از تأیید Rule، تمام Entry Pointها را Inventory کنید.

مشخص کنید Action از کجا قابل فراخوانی است:

Web،

API،

Mobile،

Webhook،

Admin.

بعد State و Data Flow را بررسی کنید.

Fix فقط روی یک Controller ممکن است کافی نباشد.

در ادامه Regression Test ایجاد کنید تا مشکل دوباره برنگردد.

اگر Vulnerability مالی بوده، Logها باید برای Abuse قبلی بررسی شوند.

Incident Response در Business Logic Abuse

Business Logic Abuse همیشه Log خطا تولید نمی‌کند.

Requestها ممکن است HTTP 200 داشته باشند.

تمام Queryها معتبر باشند.

User نیز Authentication موفق داشته باشد.

بنابراین Incident Response باید Business Eventها را بررسی کند.

مثلاً:

چه Userهایی Benefit دریافت کرده‌اند؟

چه Accountهایی Pattern مشابه دارند؟

از چه زمانی Feature قابل Abuse بوده؟

Financial Exposure چقدر است؟

آیا باید Reward یا Credit معکوس شود؟

آیا Token یا Account نیاز به Block دارد؟

این Incidentها معمولاً نیازمند همکاری AppSec، Product، Finance و Fraud Team هستند.

سؤالات متداول درباره Business Logic Vulnerability

Business Logic Vulnerability چیست؟

Business Logic Vulnerability ضعفی است که در آن Application قوانین و Workflow مورد انتظار کسب‌وکار را به‌درستی enforce نمی‌کند. در نتیجه User می‌تواند از قابلیت‌های عادی سیستم در Sequence، State، مقدار یا تعداد دفعاتی استفاده کند که کسب‌وکار انتظار نداشته است.

آیا Business Logic Vulnerability همان Insecure Design است؟

کاملاً مترادف نیستند، اما ارتباط نزدیکی دارند. OWASP Top 10:2025 نقص‌های Business Logic را یکی از نمونه‌های A06 Insecure Design می‌داند، زیرا بسیاری از آنها از Requirement یا Design ناقص ناشی می‌شوند.

CWE مربوط به Business Logic Vulnerability چیست؟

CWE-840 یک Category با عنوان Business Logic Errors است و برای Mapping مستقیم Vulnerability واقعی نباید استفاده شود. بسته به Root Cause ممکن است CWE-841 برای Workflow Sequence، CWE-837 برای Actionای که فقط یک بار باید انجام شود یا CWE دقیق دیگری مناسب باشد.

چرا Scannerها Business Logic Vulnerability را سخت پیدا می‌کنند؟

زیرا Scanner معمولاً Business Requirement سیستم را نمی‌داند. یک Request ممکن است از نظر HTTP، Syntax، Authentication و Database کاملاً معتبر باشد ولی از نظر Business Rule نامعتبر باشد. تشخیص این موضوع به شناخت Domain و Workflow نیاز دارد.

آیا Frontend Validation کافی است؟

خیر. Frontend برای UX مناسب است اما Security Control نهایی نیست. هر Rule مهم باید در Backend و نزدیک Business Operation enforce شود.

آیا Hidden Field قابل اعتماد است؟

خیر. هر داده‌ای که از Client می‌آید قابل تغییر است. Hidden Input، JavaScript State، Mobile App Parameter و Client-side Price همگی باید در Server مجدداً بررسی شوند.

آیا Business Logic Vulnerability همیشه نیازمند Payload است؟

خیر. بسیاری از این ضعف‌ها فقط با استفاده از Requestهای کاملاً معتبر در ترتیب، تعداد یا زمان‌بندی غیرمنتظره ایجاد می‌شوند.

State Machine چه کمکی می‌کند؟

State Machine مشخص می‌کند هر Workflow چه Stateهایی دارد و از هر State چه Transitionهایی مجاز هستند. Backend می‌تواند قبل از انجام Action، State فعلی را بررسی و Transition نامعتبر را Reject کند.

Race Condition چه ارتباطی با Business Logic دارد؟

اگر دو Request هم‌زمان بتوانند یک Invariant مانند Balance، Stock یا Usage Limit را دور بزنند، Race Condition باعث Business Logic Violation می‌شود. عملیات Check-Then-Act حساس باید Atomic باشد.

Idempotency Key چیست؟

Idempotency Key شناسه‌ای است که Server از آن برای تشخیص اجرای تکراری یک Business Operation استفاده می‌کند. در عملیات‌هایی مانند Payment و Order Creation می‌تواند از ایجاد نتیجه چندباره در اثر Retry جلوگیری کند.

Rate Limit برای جلوگیری از Business Logic Abuse کافی است؟

خیر. Rate Limit بخشی از دفاع است. Business Limit ممکن است مستقل از زمان باشد؛ مثلاً هر User فقط یک بار در طول عمر Account حق دریافت Reward داشته باشد.

Business Logic Vulnerability در WordPress ممکن است رخ دهد؟

بله. Pluginها و Themeهایی که Workflowهایی مثل Payment، Subscription، Coupon، Booking، Wallet یا Referral ایجاد می‌کنند می‌توانند Business Logic Flaw داشته باشند. Nonce یا Authentication به‌تنهایی کافی نیست و Capability، Ownership، State و Business Rule نیز باید بررسی شوند.

Business Logic Vulnerability در WooCommerce چگونه ایجاد می‌شود؟

معمولاً در Custom Pluginها یا Integrationهایی که Order State، Coupon، Payment، Stock، Credit یا Refund را تغییر می‌دهند. Ruleهای WooCommerce و Business Rule سفارشی باید در Backend و تمام Entry Pointها یکسان enforce شوند.

بهترین روش جلوگیری از Business Logic Vulnerability چیست؟

Business Ruleها را صریح تعریف کنید، مقادیر حساس را Server-Side محاسبه کنید، Workflowها را State Machine کنید، Authorization را Contextual انجام دهید، عملیات حساس را Atomic و Idempotent طراحی کنید، Limits را در Backend enforce کنید و Threat Modeling و Misuse Testing داشته باشید.

آیا WAF می‌تواند Business Logic Vulnerability را متوقف کند؟

معمولاً نه به‌عنوان کنترل اصلی. Request ممکن است کاملاً Valid باشد و هیچ Signature مخربی نداشته باشد. WAF می‌تواند لایه مکمل برای Rate Limit یا Detection باشد اما Business Rule باید داخل Application enforce شود.

جمع‌بندی

Business Logic Vulnerability یکی از مهم‌ترین و در عین حال سخت‌ترین دسته‌های ضعف در امنیت وب است، زیرا Application در بسیاری از موارد از نظر فنی کاملاً درست کار می‌کند.

هیچ SQL Injection وجود ندارد.

هیچ XSS وجود ندارد.

Request نیز ممکن است کاملاً معتبر باشد.

اما User از یک قابلیت مشروع در حالتی استفاده می‌کند که Product و Developer انتظار آن را نداشته‌اند.

ریشه اصلی مشکل معمولاً یک فرض ناگفته است.

توسعه‌دهنده فرض می‌کند User مراحل UI را به ترتیب طی می‌کند.

فرض می‌کند Button غیرفعال‌شده دوباره قابل استفاده نیست.

فرض می‌کند Request فقط یک بار می‌رسد.

فرض می‌کند دو Request هم‌زمان نمی‌آیند.

فرض می‌کند Price ارسالی از Frontend تغییر نمی‌کند.

فرض می‌کند User از Feature بیش از حد استفاده نخواهد کرد.

امنیت زمانی ایجاد می‌شود که این فرض‌ها به Ruleهای صریح و قابل enforce تبدیل شوند.

Workflowهای چندمرحله‌ای باید State Machine Server-Side داشته باشند.

هر Transition باید براساس State فعلی Validate شود.

قیمت، Ownership، Permission و سایر Security-Relevant Valueها باید از Source معتبر Server-Side تعیین شوند.

Actionهای مالی و Check-Then-Act باید Atomic باشند.

Retryها نباید باعث اجرای دوباره Transaction شوند و برای Operationهای مناسب باید Idempotency در نظر گرفته شود.

Limitهای Business مانند Coupon، Trial، Reward و Reservation باید مستقل از UI در Backend enforce شوند.

Sensitive Business Flowها باید برای Automation و Bot Abuse نیز Threat Model شوند؛ موضوعی که OWASP API Security Top 10:2023 در API6 Unrestricted Access to Sensitive Business Flows روی آن تأکید می‌کند.

همچنین باید میان CWE-840 و CWEهای قابل نگاشت تفاوت گذاشت. CWE-840 صرفاً Category مربوط به Business Logic Errors است و MITRE توصیه می‌کند برای Vulnerability واقعی Root Cause دقیق، مانند CWE-841 برای Enforcement نامناسب Workflow، انتخاب شود.

در OWASP Top 10:2025، Business Logic Flawها ارتباط مستقیمی با A06 Insecure Design دارند. OWASP توصیه می‌کند Business Logic و Critical Flowها از مرحله Design وارد Threat Modeling، User Story و Unit/Integration Testing شوند.

بنابراین مهم‌ترین پرسش هنگام بررسی امنیت منطق تجاری این نیست:

«آیا User یک Payload مخرب وارد می‌کند؟»

پرسش مهم‌تر این است:

«اگر User کاملاً آگاهانه، متقلبانه و برخلاف فرضیات ما از قابلیت‌های قانونی سیستم استفاده کند، آیا Backend همچنان تمام قوانین واقعی کسب‌وکار را enforce می‌کند؟»

پاسخ دقیق به همین سؤال بسیاری از Business Logic Vulnerabilityهای خطرناک را قبل از رسیدن به Production آشکار می‌کند. # Business Logic Vulnerability چیست؟ بررسی آسیب‌پذیری منطق تجاری در وب‌سایت‌ها

Business Logic Vulnerability یا «آسیب‌پذیری منطق تجاری» زمانی ایجاد می‌شود که یک وب‌سایت یا نرم‌افزار از نظر فنی درست کار کند، اما قوانین واقعی کسب‌وکار را به‌درستی enforce نکند. در چنین شرایطی کاربر ممکن است بدون SQL Injection، XSS یا Payload خاص، از قابلیت‌های عادی سایت به ترتیبی استفاده کند که توسعه‌دهنده انتظار نداشته است؛ برای مثال مرحله‌ای الزامی را دور بزند، یک مزیت را بیش از تعداد مجاز دریافت کند، عملیاتی را در وضعیت نامعتبر انجام دهد یا دو Request هم‌زمان باعث ثبت نتیجه‌ای شوند که از نظر کسب‌وکار نباید امکان‌پذیر باشد.

مهم‌ترین راه جلوگیری از Business Logic Vulnerability این است که قوانین کسب‌وکار به‌صورت صریح تعریف و در سمت Server enforce شوند. Workflowها باید State Machine مشخص داشته باشند، قیمت و مالکیت و Permission از Server تعیین شوند، عملیات حساس Atomic و Idempotent طراحی شوند، محدودیت استفاده از قابلیت‌ها در Backend اعمال شود و تیم امنیت هنگام Threat Modeling فقط نپرسد «مهاجم چگونه Code را می‌شکند؟»، بلکه بپرسد «یک کاربر متقلب چگونه از قابلیت کاملاً سالم سیستم برخلاف هدف کسب‌وکار استفاده می‌کند؟»

Business Logic Vulnerability چیست؟

بسیاری از آسیب‌پذیری‌های وب را می‌توان با یک الگوی فنی مشخص توضیح داد.

در SQL Injection، ورودی غیرقابل‌اعتماد وارد Query می‌شود.

در XSS، داده کنترل‌شده توسط مهاجم در Context مرورگر به‌شکل ناامن قرار می‌گیرد.

در Path Traversal، User Input روی مسیر فایل اثر می‌گذارد.

اما Business Logic Vulnerability الزاماً چنین Signature مشخصی ندارد.

ممکن است تمام Inputها Validate شده باشند.

Queryها Parameterized باشند.

Outputها Encode شده باشند.

CSRF Protection نیز وجود داشته باشد.

با این حال فرایند خرید، پرداخت، رزرو یا اعمال تخفیف هنوز از نظر منطقی آسیب‌پذیر باشد.

OWASP Business Logic Security Cheat Sheet این مسئله را به‌صورت تفاوت میان «آنچه Developer به سیستم گفته انجام دهد» و «آنچه کسب‌وکار واقعاً انتظار دارد» توضیح می‌دهد. Code ممکن است دقیقاً همان چیزی را اجرا کند که نوشته شده، اما Requirement امنیتی یا Business Rule ناقص تعریف شده باشد.

فرض کنید فروشگاه قانونی دارد:

هر کد تخفیف فقط یک بار برای هر سفارش قابل استفاده است.

اگر Frontend بعد از یک بار استفاده دکمه اعمال تخفیف را غیرفعال کند ولی Backend بتواند همان عملیات را دوباره انجام دهد، سیستم از نظر UI درست به نظر می‌رسد اما Business Rule واقعی enforce نشده است.

این یک تفاوت بنیادی با بسیاری از Vulnerabilityهای سنتی دارد.

در اینجا مهاجم لزوماً Syntax یا Parser را نمی‌شکند.

او «فرضیات برنامه» را می‌شکند.

منطق تجاری یا Business Logic دقیقاً چیست؟

Business Logic مجموعه قواعدی است که تعیین می‌کند یک Application در دنیای واقعی چگونه باید رفتار کند.

برای یک فروشگاه اینترنتی، قوانین منطق تجاری می‌توانند شامل مواردی مانند این باشند:

چه کسی اجازه خرید دارد؟

قیمت نهایی چگونه محاسبه می‌شود؟

چه زمانی Discount معتبر است؟

کاربر چند بار می‌تواند از یک Coupon استفاده کند؟

آیا محصول موجود است؟

در چه زمانی موجودی باید کاهش پیدا کند؟

Refund در چه شرایطی مجاز است؟

سفارش بعد از ارسال می‌تواند لغو شود یا خیر؟

برای یک بانک، Business Ruleها متفاوت‌اند.

مثلاً:

Transfer باید از Account متعلق به همان User انجام شود.

Transfer بزرگ نیازمند Authorization اضافه است.

مبلغ برداشت نمی‌تواند بیشتر از موجودی قابل استفاده باشد.

یک Transaction تأییدشده نباید دوباره اجرا شود.

در یک سایت رزرو نیز قواعد ممکن است شامل ظرفیت، تاریخ، مالکیت Reservation، محدودیت تعداد رزرو و وضعیت پرداخت باشند.

در نتیجه Business Logic کاملاً Domain-Specific است.

به همین دلیل Scanner نمی‌تواند صرفاً با داشتن یک Pattern ثابت تمام Business Logic Vulnerabilityها را کشف کند.

چرا آسیب‌پذیری‌های منطق تجاری با باگ‌های عادی فرق دارند؟

Business Logic Bug می‌تواند در Code کاملاً Valid وجود داشته باشد.

برای مثال فرض کنید Backend چنین قانونی دارد:

اگر سفارش وجود دارد، اجازه لغو بده.

این کد از نظر Syntax و Runtime مشکلی ندارد.

اما Requirement واقعی شاید این باشد:

سفارش باید متعلق به User فعلی باشد،
هنوز ارسال نشده باشد،
Refund دیگری برای آن ثبت نشده باشد،
و وضعیت آن در یکی از Stateهای قابل لغو قرار داشته باشد.

فاصله بین این دو تعریف، همان جایی است که Business Logic Vulnerability شکل می‌گیرد.

OWASP WSTG تأکید می‌کند که تست منطق تجاری به شناخت کامل Business Process نیاز دارد و بسیاری از این مشکلات به‌راحتی با Vulnerability Scannerهای معمول قابل کشف نیستند. Tester باید Misuse Caseها، Sequenceها و حالت‌های غیرعادی را بررسی کند.

Business Logic Vulnerability چگونه ایجاد می‌شود؟

معمولاً یک علت منفرد وجود ندارد.

در اغلب موارد چند فرض اشتباه در کنار یکدیگر قرار می‌گیرند.

یکی از رایج‌ترین فرض‌ها این است:

کاربر همان مسیری را طی می‌کند که UI طراحی کرده است.

اما User کنترل HTTP Client خود را دارد.

او مجبور نیست حتماً دکمه‌ها را به ترتیب بزند.

می‌تواند Requestهایی را که Browser ارسال می‌کند مستقیماً ایجاد، تکرار یا در ترتیب متفاوت ارسال کند.

به همین دلیل Frontend بخشی از UX است، نه Boundary امنیتی.

اعتماد به ترتیب صفحات

فرض کنید فرایند خرید شامل چهار مرحله باشد:

Cart
 ↓
Address
 ↓
Payment
 ↓
Order Confirmation

Developer ممکن است فرض کند User فقط از Cart به Address و سپس Payment می‌رود.

اما امنیت باید در Backend تضمین کند که رسیدن به مرحله آخر فقط زمانی ممکن است که تمام Preconditionهای لازم واقعاً برقرار باشند.

OWASP این مسئله را در تست Circumvention of Work Flows مطرح می‌کند و می‌گوید Application باید اطمینان حاصل کند مراحل لازم در ترتیب درست انجام شده‌اند؛ اگر Workflow ناقص رها شود، Actionهای وابسته نیز باید Cancel یا Rollback شوند.

دور زدن مراحل Workflow

یکی از شناخته‌شده‌ترین Business Logic Vulnerabilityها زمانی رخ می‌دهد که User بتواند مرحله‌ای ضروری را Skip کند.

فرض کنید ثبت حساب چنین Workflowای دارد:

Create Account
      ↓
Email Verification
      ↓
Profile Completion
      ↓
Account Activation

اگر Backend Endpoint نهایی فقط بررسی کند که Account وجود دارد و بررسی نکند Email Verification واقعاً تکمیل شده، UI هرچقدر هم مرحله Verification را اجباری نشان دهد کافی نیست.

این ضعف از نظر CWE می‌تواند در شرایط مناسب با CWE-841 یعنی Improper Enforcement of Behavioral Workflow مرتبط باشد. MITRE این ضعف را حالتی تعریف می‌کند که Product دارای چند رفتار متوالی است ولی تضمین نمی‌کند Actor آنها را در Sequence موردنیاز انجام دهد.

انجام مراحل خارج از ترتیب

مشکل همیشه Skip کردن نیست.

گاهی همان مراحل انجام می‌شوند اما در ترتیب نامعتبر.

مثلاً یک Transaction ممکن است به‌صورت طراحی‌شده چنین باشد:

Create
 ↓
Validate
 ↓
Authorize
 ↓
Execute

اگر Endpoint Execute بدون بررسی State فعلی Transaction قابل فراخوانی باشد، User ممکن است از مسیر مورد انتظار خارج شود.

State نباید از URL یا صفحه‌ای که User روی آن قرار دارد استنباط شود.

Server باید خودش State واقعی Workflow را ذخیره کند.

اعتماد به داده‌های سمت Client

یکی از مهم‌ترین ریشه‌های Business Logic Vulnerability اعتماد به داده‌ای است که باید Server آن را محاسبه کند.

فرض کنید Browser هنگام Checkout چنین داده‌ای ارسال کند:

{
  "product_id": 50,
  "quantity": 2,
  "unit_price": 300
}

Application ممکن است واقعاً به product_id و quantity نیاز داشته باشد.

اما unit_price باید از Server-side Product Catalog به دست آید.

اگر Price ارسال‌شده توسط Client مبنای Charge قرار گیرد، Business Rule مهمی شکسته شده است:

قیمت، حقیقتی Server-Side است؛
نه ادعایی Client-Side.

OWASP Business Logic Security Cheat Sheet توصیه می‌کند مقادیر امنیتی مانند Price، Ownership، Identity و Permission از منابع Server-Side مشتق شوند و Client State صرفاً Input در نظر گرفته شود.

اعتماد به Hidden Field

Hidden Input نیز Trusted نیست.

مثلاً:

<input type="hidden" name="plan" value="basic">

فقط به این دلیل که User مقدار را در UI نمی‌بیند نمی‌توان Backend را از Validation معاف کرد.

Hidden Field، Disabled Input، JavaScript Variable، Mobile App Parameter و هر داده‌ای که از Client می‌آید قابل تغییر است.

Business Rule باید در Backend اعمال شود.

محدودیت تعداد استفاده از یک قابلیت

برخی Featureها فقط تعداد مشخصی بار باید قابل استفاده باشند.

برای مثال:

یک Coupon یک بار،

یک Trial یک بار،

سه Download در ماه،

یک Referral Reward برای هر User معتبر،

یک Vote برای هر Account،

یک درخواست Reset در بازه زمانی مشخص.

اگر Backend این Limit را enforce نکند، Business Logic Vulnerability ایجاد می‌شود.

OWASP WSTG بخش مستقلی برای تست «تعداد دفعات استفاده از Function» دارد و تأکید می‌کند Application باید خودش محدودیت استفاده از Feature را enforce کند؛ برای مثال Discount نباید بیش از دفعات تعیین‌شده اعمال شود یا Subscription Limit نباید قابل دور زدن باشد.

تفاوت Rate Limit با Business Limit

این دو مفهوم یکسان نیستند.

Rate Limit می‌گوید:

حداکثر 10 Request در دقیقه.

Business Limit ممکن است بگوید:

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

ممکن است Rate Limit کاملاً صحیح باشد اما User هر ده دقیقه یک بار Benefit جدید دریافت کند و در نهایت Business Rule را دور بزند.

بنابراین Feature-Level Limit و Network/API Rate Limit باید جداگانه طراحی شوند.

آسیب‌پذیری در سیستم‌های تخفیف

Discount Systemها نمونه کلاسیک Business Logic هستند.

قوانین ممکن است پیچیده باشند:

Coupon A فقط برای User جدید است.

Coupon B فقط روی Category مشخص اعمال می‌شود.

دو Coupon نباید هم‌زمان استفاده شوند.

Discount کل نباید از مبلغ سفارش بیشتر شود.

Coupon بعد از Refund نباید دوباره Benefit ایجاد کند.

یک Promotion ممکن است Expiration Time داشته باشد.

هر یک از این موارد یک Invariant است.

اگر یکی از آنها فقط در UI enforce شود یا در یکی از چند Endpoint بررسی نشود، امکان سوءاستفاده منطقی ایجاد می‌شود.

راهکار امن این نیست که مجموعه‌ای از Inputهای «مشکوک» را Block کنیم.

باید Business Ruleهای قابل قبول را دقیق تعریف و enforce کنیم.

قیمت منفی، صفر و مقادیر غیرمنطقی

Validation فقط درباره Data Type نیست.

ممکن است quantity از نوع Integer باشد اما مقدار آن از نظر Business غیرممکن باشد.

به همین دلیل باید میان Syntax Validation و Semantic Validation تفاوت قائل شد.

مثلاً:

quantity باید Integer باشد.

یک Rule فنی است.

اما:

quantity باید بین 1 و حداکثر موجودی قابل فروش باشد.

Business Validation است.

OWASP Top 10:2025 در A06 Insecure Design توصیه می‌کند Plausibility Check در لایه‌های مختلف Application اجرا شود؛ یعنی سیستم علاوه بر معتبر بودن فرمت داده، منطقی بودن آن نسبت به Domain را نیز بررسی کند.

Business Logic Vulnerability در پرداخت

Payment Flow یکی از حساس‌ترین Workflowهای سایت است.

یک Order ممکن است Stateهای زیر داشته باشد:

CREATED
  ↓
AWAITING_PAYMENT
  ↓
PAID
  ↓
PROCESSING
  ↓
SHIPPED

نباید Client بتواند خودش Status را به PAID تغییر دهد.

همچنین Redirect شدن User از Payment Gateway به سایت به‌تنهایی نباید دلیل پرداخت موفق باشد.

Server باید نتیجه Transaction را از Source معتبر بررسی کند.

مبلغ و Currency نیز باید با سفارش اصلی مطابقت داشته باشند.

یک Payment ID نباید بتواند Order دیگری را Paid کند.

Callback تکراری نباید Order یا Credit را چند بار ثبت کند.

این موارد Business Rule هستند.

Authorization تراکنش

برای عملیات بسیار حساس، Authentication معمولی ممکن است کافی نباشد.

مثلاً انتقال وجه می‌تواند نیازمند Transaction Authorization باشد.

OWASP Transaction Authorization Cheat Sheet توصیه می‌کند Authorization عملیات کاملاً در Server enforce شود و State Transitionهای Transaction در ترتیب موردنظر کنترل شوند. تغییر اطلاعات مهم Transaction باید Authorization قبلی را نامعتبر کند یا Process را از ابتدا آغاز کند.

اصل مهم این است:

User نباید یک Transaction را برای داده A تأیید کند و سپس داده Transaction به B تغییر کند درحالی‌که Authorization اولیه همچنان معتبر باقی مانده است.

Race Condition و Business Logic

برخی Business Logic Vulnerabilityها فقط با Requestهای هم‌زمان ظاهر می‌شوند.

فرض کنید User دقیقاً 100 واحد اعتبار دارد.

دو Request خرید تقریباً هم‌زمان ارسال می‌شوند.

هر Request ابتدا می‌خواند:

balance = 100

و هر دو نتیجه می‌گیرند خرید 80 واحدی مجاز است.

اگر عملیات:

Check Balance
 ↓
Charge
 ↓
Update Balance

Atomic نباشد، هر دو Transaction ممکن است موفق شوند.

این مشکل فقط یک Performance Issue نیست.

Business Invariant:

موجودی هرگز نباید منفی شود

شکسته شده است.

OWASP Business Logic Security Cheat Sheet توصیه می‌کند Concurrency را بخشی از Threat Model بدانیم و عملیات Check-Then-Act را با Transaction، Lock یا Conditional Update به‌صورت Atomic طراحی کنیم.

Atomicity چیست؟

Atomic Operation یعنی یک Business Action حساس یا کاملاً انجام شود یا اصلاً انجام نشود.

فرض کنید خرید باید:

موجودی را کاهش دهد،

Payment Record بسازد،

Order ایجاد کند،

و Coupon را مصرف‌شده علامت بزند.

اگر دو مرحله اول موفق شوند و مرحله سوم Fail شود، سیستم ممکن است وارد State ناسازگار شود.

Database Transaction، Idempotency، Retry Policy و Rollback Strategy باید با Business Rule هماهنگ باشند.

Idempotency چیست و چرا برای Business Logic مهم است؟

یک Operation Idempotent به شکلی طراحی می‌شود که اجرای چندباره همان Request نتیجه ناخواسته چندباره ایجاد نکند.

فرض کنید Client به‌دلیل Timeout مطمئن نیست Payment ثبت شده یا نه و Request را Retry می‌کند.

بدون کنترل مناسب ممکن است:

دو Order ساخته شود،

دو Charge ثبت شود،

دو Credit داده شود.

برای عملیات Non-Idempotent حساس، Idempotency Key می‌تواند کمک کند Server Request تکراری را تشخیص دهد و همان نتیجه قبلی را برگرداند، نه اینکه عملیات را دوباره انجام دهد.

این کنترل به‌خصوص برای Payment، Order Creation، Transfer و Reward اهمیت دارد.

Reservation و موجودی

سیستم رزرو یکی دیگر از محل‌های رایج Business Logic Abuse است.

Rule ممکن است بگوید:

یک Seat فقط یک بار قابل رزرو است.

Reservation بدون پرداخت فقط ده دقیقه معتبر است.

هر User حداکثر سه Slot فعال دارد.

ظرفیت کل باید رعایت شود.

اگر Reservation موقت منابع واقعی را بدون محدودیت Lock کند، یک User می‌تواند Availability را برای Userهای واقعی کاهش دهد.

OWASP API Security Top 10:2023 این مفهوم را در API6:2023 یعنی Unrestricted Access to Sensitive Business Flows مطرح می‌کند. Flowهایی مانند خرید، ارسال Comment و Reservation اگر محدودیت مناسب نداشته باشند ممکن است با استفاده بیش از حد به خود کسب‌وکار آسیب بزنند.

Business Logic Abuse و Automation

یک Feature ممکن است در استفاده انسانی کاملاً منطقی باشد اما با Automation خطرناک شود.

مثلاً یک سایت Ticketing فرض می‌کند هر انسان در هر دقیقه فقط چند Action انجام می‌دهد.

اما Bot می‌تواند هزاران Request ایجاد کند.

این مسئله لزوماً Authentication Failure نیست.

User ممکن است Account معتبر داشته باشد.

Endpoint نیز دقیقاً همان کاری را انجام دهد که طراحی شده است.

مشکل این است که Business Requirement مشخص نکرده Feature با چه Scale و Frequency مجاز است.

OWASP API6:2023 دقیقاً روی همین موضوع تمرکز دارد: Business Flow حساس اگر برای Access بیش از حد یا Automation محافظت نشده باشد، می‌تواند به ضرر کسب‌وکار منجر شود.

Referral و سیستم پاداش

سیستم Referral، Cashback، Loyalty Point و Bonus از Featureهای بسیار مستعد Business Logic Abuse هستند.

Business Ruleها باید مشخص کنند:

Referral واقعی چیست؟

آیا دو Account مرتبط می‌توانند یکدیگر را Referral کنند؟

Reward چه زمانی Final می‌شود؟

اگر Transaction Refund شد چه اتفاقی می‌افتد؟

آیا Reward Pending باید قابل خرج باشد؟

User چند بار می‌تواند Benefit دریافت کند؟

اگر این Rules فقط در سطح UI تعریف شوند، Abuse امکان‌پذیر است.

Refund Logic

Refund باید یک State Machine باشد.

برای مثال:

PAID
 ↓
REFUND_REQUESTED
 ↓
APPROVED
 ↓
REFUNDED

یک Order نباید دو بار Refund شود.

Refund نباید بیش از مبلغ Paid باشد.

Item Refundشده نباید دوباره بدون Rule مشخص Reward تولید کند.

Refund و Coupon و Loyalty Point باید با هم سازگار باشند.

مشکلات مالی زیادی نه از Injection بلکه از همین ناسازگاری بین Subsystemها ایجاد می‌شوند.

ثبت‌نام و Trial Abuse

یک SaaS ممکن است به هر User هفت روز Trial بدهد.

اما «هر User» باید تعریف شود.

آیا:

هر Email؟

هر Account؟

هر شخص؟

هر Payment Method؟

هر Organization؟

اگر Business Rule فقط روی Account ID اعمال شود، User ممکن است بتواند Accountهای متعددی بسازد.

راهکار لزوماً Block سخت‌گیرانه نیست.

باید Threat Model و Business Model تعیین کنند چه سطح Abuse قابل قبول است.

تغییر Email و Business Logic

تغییر Email در ظاهر Feature ساده‌ای است.

اما Rules زیادی دارد:

User باید Session معتبر داشته باشد.

ممکن است Reauthentication لازم باشد.

Email جدید نباید متعلق به Account دیگری باشد.

Email جدید باید Verify شود.

تا قبل از Verification، Email قبلی نباید فوراً بدون Recovery Path حذف شود.

Sessionهای حساس شاید نیاز به Refresh داشته باشند.

یک Feature ساده وقتی به State Transition تبدیل می‌شود پیچیدگی امنیتی زیادی پیدا می‌کند.

Password Reset و Workflow Logic

Password Reset نمونه مهم دیگری است.

فرایند امن باید میان:

درخواست Reset،

تولید Token،

تأیید Token،

انتخاب Password جدید،

Invalidation Token

رابطه مشخصی داشته باشد.

Token نباید پس از استفاده مجدداً معتبر باشد.

تغییر Account Data نباید Token را به Account دیگری مرتبط کند.

Reset Process باید در Server State ذخیره شود.

این موارد Business Workflow Security هستند، حتی اگر Token از نظر Cryptography قوی باشد.

نقش Fail Open در Business Logic

فرض کنید Service مربوط به بررسی Limit موقتاً unavailable شود.

Application دو انتخاب دارد:

اگر Check شکست خورد، اجازه عملیات بده.

یا:

اگر Check امنیتی تکمیل نشد، عملیات حساس را متوقف کن.

در عملیات حساس، Fail Open می‌تواند Business Rule را بی‌اثر کند.

OWASP Top 10:2025 دسته A10 Mishandling of Exceptional Conditions را برای خطاهای ناشی از شرایط غیرعادی، Fail Open و Logical Error معرفی کرده است. Business Logic باید برای Failure Stateها نیز Rule مشخص داشته باشد.

Business Logic Vulnerability و Access Control

Business Logic و Access Control همپوشانی زیادی دارند.

Authentication پاسخ می‌دهد:

این User چه کسی است؟

Authorization پاسخ می‌دهد:

این User اجازه انجام این Action را دارد؟

اما Business Authorization سؤال دقیق‌تری دارد:

آیا این User اجازه دارد
این Action را
روی این Object،
در این State،
با این مقدار،
در این زمان
انجام دهد؟

OWASP Authorization Cheat Sheet نیز تأکید می‌کند Authentication به‌تنهایی به معنی مجاز بودن تمام Actionها نیست. Authorization باید براساس Context واقعی Resource و Operation انجام شود.

Contextual Authorization چیست؟

فرض کنید Manager اجازه Approve کردن Expense را دارد.

Rule فقط این نیست:

role == manager

ممکن است Rule واقعی چنین باشد:

User مدیر است،
Expense متعلق به Team اوست،
Expense را خودش ایجاد نکرده،
Amount در Limit اختیار اوست،
Expense هنوز Pending است.

این Authorization وابسته به Business Context است.

Middleware عمومی Role Check ممکن است نتواند تمام این قواعد را اجرا کند.

بنابراین بخشی از Authorization باید نزدیک Business Operation قرار گیرد.

تفاوت Business Logic Vulnerability با IDOR

IDOR معمولاً زمانی مطرح می‌شود که User با تغییر Identifier به Object دیگری دسترسی پیدا می‌کند و Ownership به‌درستی بررسی نمی‌شود.

Business Logic Vulnerability دامنه وسیع‌تری دارد.

ممکن است اصلاً Resource متعلق به User دیگری وجود نداشته باشد.

مثلاً User روی Order خودش Actionی انجام دهد که در آن State مجاز نیست.

بنابراین IDOR می‌تواند یکی از مشکلات Business Context باشد، اما هر Business Logic Vulnerability یک IDOR نیست.

تفاوت Business Logic Vulnerability با SQL Injection

در SQL Injection مشکل Interpreter است.

User Data به Query Syntax تبدیل می‌شود.

در Business Logic Vulnerability ممکن است Database Query کاملاً Parameterized باشد و هیچ Injection رخ ندهد.

اما Application نتیجه Business اشتباه تولید کند.

این تفاوت نشان می‌دهد چرا Scannerهای Signature-Based برای Business Logic محدودیت دارند.

تفاوت Business Logic Vulnerability با XSS

XSS معمولاً دارای Context فنی مشخص در HTML، JavaScript یا DOM است.

Business Logic به Workflow و Rule مربوط است.

یک Checkout آسیب‌پذیر ممکن است هیچ Script Injection نداشته باشد اما همچنان اجازه Discount نامعتبر یا Workflow Bypass بدهد.

تفاوت Business Logic Vulnerability با Race Condition

Race Condition می‌تواند یکی از Root Causeهای Business Logic Violation باشد.

اما Business Logic Vulnerabilityهای زیادی بدون Concurrency رخ می‌دهند.

مثلاً:

Skip مرحله Verification،

استفاده بیش از حد Coupon،

تغییر Price،

استفاده از Feature در State نامعتبر.

Race Condition یک Pattern فنی مشخص‌تر است.

Business Logic Failure نتیجه شکستن Rule Domain است.

CWE مربوط به Business Logic Vulnerability چیست؟

این بخش نیازمند دقت است.

CWE-840 با عنوان Business Logic Errors یک Category است، نه یک Weakness قابل استفاده مستقیم برای نگاشت Vulnerability واقعی.

MITRE صراحتاً Usage آن را برای Vulnerability Mapping برابر PROHIBITED قرار داده است و توصیه می‌کند Root Cause دقیق شناسایی و CWE مناسب‌تر انتخاب شود.

برای مثال Workflow Bypass ممکن است با CWE-841 یعنی Improper Enforcement of Behavioral Workflow مرتبط باشد.

اگر Action باید فقط یک بار قابل اجرا باشد، CWE-837 یعنی Improper Enforcement of a Single, Unique Action می‌تواند مرتبط باشد.

اگر Ownership بررسی نشده، CWE دیگری مناسب خواهد بود.

بنابراین عبارت:

CWE-840 = تمام Business Logic Vulnerabilityها

بیان دقیقی نیست.

Business Logic در OWASP Top 10:2025

Business Logic Vulnerability به‌صورت یک عنوان مستقل در OWASP Top 10:2025 وجود ندارد.

اما OWASP آن را به‌طور واضح در A06:2025 Insecure Design پوشش می‌دهد.

OWASP در توضیح Insecure Design به نقص‌های Business Logic مانند تعریف نکردن State Changeهای ناخواسته یا غیرمنتظره اشاره می‌کند و Threat Modeling، Secure Design و تست Critical Flowها را از راهکارهای اصلی می‌داند.

این نکته مهم است.

Business Logic Vulnerability اغلب یک مشکل Design-Time است.

اگر Business Rule هرگز تعریف نشده باشد، Developer نمی‌تواند چیزی را enforce کند که وجود ندارد.

چرا Scannerها معمولاً Business Logic Vulnerability را پیدا نمی‌کنند؟

Scanner می‌تواند Patternهای زیادی را آزمایش کند.

مثلاً Characterهای SQL را وارد Input کند.

HTML را Reflect کند.

Header را بررسی کند.

Directory را Crawl کند.

اما چگونه Scanner بداند:

هر User فقط یک Bonus باید داشته باشد؟

Refund بعد از Shipping ممنوع است؟

Manager اجازه Approve کردن Request خودش را ندارد؟

Coupon A با Coupon B نباید ترکیب شود؟

Reservation بدون پرداخت فقط ده دقیقه معتبر است؟

این Knowledge داخل Business Domain قرار دارد.

MITRE نیز می‌گوید Business Logic Errorها برای Automated Analysis دشوارند چون عملیات معمولاً از نظر Code کاملاً Legitimate هستند و برای تشخیص Weakness به Domain-Specific Knowledge نیاز است.

آیا تست خودکار برای Business Logic بی‌فایده است؟

خیر.

تست خودکار بسیار مفید است؛ اما ابتدا Human باید Rule را تعریف کند.

پس از آن می‌توان Unit Test، Integration Test و Property-Based Test نوشت.

مثلاً Business Invariant:

RefundTotal <= PaidTotal

را می‌توان خودکار تست کرد.

یا:

Order SHIPPED cannot transition to CANCELLED

می‌تواند Regression Test داشته باشد.

بنابراین مشکل Automation این نیست که هیچ کاری نمی‌تواند انجام دهد.

مسئله این است که Tool نمی‌تواند Business Requirement ناشناخته را از خودش اختراع کند.

Business Invariant چیست؟

Invariant قانونی است که در تمام Stateهای معتبر سیستم باید برقرار باشد.

مثلاً:

Account Balance cannot become negative.

یا:

A coupon can only be redeemed once per eligible account.

یا:

A refunded order cannot generate another loyalty reward.

یا:

Only an owner can cancel an active reservation.

یکی از بهترین روش‌های Secure Design این است که این Invariantها قبل از Coding نوشته شوند.

برای هر Rule باید مشخص شود:

کدام Component آن را enforce می‌کند؟

در چه Transaction Boundary؟

در چه Database Constraint؟

با چه Test؟

State Machine در طراحی امن

برای Workflowهای چندمرحله‌ای، State Machine یکی از مؤثرترین الگوهاست.

فرض کنیم KYC دارای Stateهای زیر باشد:

NOT_STARTED
   ↓
SUBMITTED
   ↓
UNDER_REVIEW
   ↓
APPROVED

Transitionهای مجاز باید صریح باشند.

مثلاً:

Backend باید هر Transition را بررسی کند.

Frontend فقط State را نمایش می‌دهد.

OWASP Business Logic Security Cheat Sheet نیز توصیه می‌کند Workflowهای چندمرحله‌ای به State Machine صریح در Server تبدیل شوند و هر Transition نسبت به State فعلی Validate شود.

تست Business Logic از کجا شروع می‌شود؟

اول باید Application را از دید Business بفهمید.

نه فقط URLها را.

تیم تست باید بداند:

دارایی ارزشمند چیست؟

چه Featureهایی Money یا Credit جابه‌جا می‌کنند؟

چه Featureهایی Permission تغییر می‌دهند؟

چه Workflowهایی چندمرحله‌ای هستند؟

کدام Action محدودیت دفعات دارد؟

چه چیزی باید فقط یک بار اتفاق بیفتد؟

چه Stateهایی Terminal هستند؟

چه Ruleهایی میان چند Service مشترک‌اند؟

OWASP WSTG نیز تست Business Logic را وابسته به فهم Business Process و Rules می‌داند.

تست ترتیب Workflow

در محیط مجاز می‌توان بررسی کرد آیا Backend مراحل را مستقل Validate می‌کند.

هدف این نیست که Process واقعی مشتریان را مختل کنیم.

در Staging یک Workflow آزمایشی ساخته می‌شود.

سپس Sequenceهای مجاز و نامعتبر تست می‌شوند.

مثلاً:

Step 1 → Step 2 → Step 3

و:

Step 1 → Step 3

یا تکرار Step 2.

انتظار باید از قبل مشخص باشد.

تست Request خارج از UI

Backend نباید فرض کند Request فقط از Official Frontend می‌آید.

OWASP WSTG بخشی با عنوان Test Ability to Forge Requests دارد و توضیح می‌دهد مهاجم می‌تواند GUI را دور بزند و Requestهای GET/POST را مستقیماً با مقادیری بفرستد که UI اجازه تولید آنها را نمی‌دهد.

در تست دفاعی باید بررسی شود Backend خودش Rules را enforce می‌کند.

تست محدودیت‌ها

اگر Documentation می‌گوید:

حداکثر پنج Item،

یک Discount،

سه Download،

دو Reservation،

یک Reward،

همه این Rules باید در Server قابل تست باشند.

Boundary Test مهم است.

مثلاً اگر Limit برابر 3 است:

1، 2، 3 باید رفتار مجاز داشته باشند.

4 باید رفتار مشخص و امن داشته باشد.

همچنین اجرای Parallel باید بررسی شود تا Race Condition Limit را دور نزند.

تست Failure State

یکی از مهم‌ترین بخش‌هایی که اغلب فراموش می‌شود Failure است.

اگر Payment Provider Timeout شود چه؟

اگر Database Update دوم Fail شود چه؟

اگر Email Verification ارسال شود ولی State Update Fail کند چه؟

اگر Callback دوبار برسد چه؟

اگر Worker Job Retry شود چه؟

اگر User Browser را در میانه Workflow ببندد چه؟

Security فقط Happy Path نیست.

سیستم باید برای Partial Failure نیز State امن داشته باشد.

تست نقش‌ها

Business Rule ممکن است برای Roleهای مختلف متفاوت باشد.

مثلاً:

Customer می‌تواند Order خود را Cancel کند.

Support می‌تواند Cancel درخواست‌شده را بررسی کند.

Finance می‌تواند Refund انجام دهد.

Administrator می‌تواند Override کند.

اما Override نیز باید Audit Trail داشته باشد.

هر Role باید در هر State بررسی شود.

تست Cross-Channel

بسیاری از سیستم‌ها چند Interface دارند:

Web،

Mobile،

REST API،

Admin Panel،

Webhook،

Legacy API.

ممکن است Business Rule در Web جدید enforce شود ولی API قدیمی همان عملیات را بدون کنترل انجام دهد.

OWASP Business Logic Security Cheat Sheet توصیه می‌کند تمام Entry Pointهای یک Sensitive Operation شناسایی شوند و همان Business Ruleها روی همه آنها اعمال شوند.

چگونه از Business Logic Vulnerability جلوگیری کنیم؟

اولین قدم این است که Security را بخشی از Business Requirement بدانیم.

نگوییم:

User can use coupon.

Rule باید دقیق باشد:

Verified users can redeem coupon X once
on eligible products,
before expiration,
and coupon X cannot be combined with coupon Y.

هرچه Requirement مبهم‌تر باشد، Implementationهای متفاوت‌تری ایجاد می‌شوند.

قوانین را در Server enforce کنید

Frontend قابل اعتماد نیست.

Mobile App نیز قابل اعتماد نیست.

حتی Official Client قابل تغییر و Reverse Engineering است.

Backend باید منبع حقیقت باشد.

قیمت، Ownership، Role، Eligibility، Limit و State از Server-side Sources به دست آیند.

Security-Relevant Value را دوباره محاسبه کنید

برای Checkout:

Client می‌گوید چه Product و Quantity می‌خواهد.

Server محاسبه می‌کند:

Price،

Tax،

Discount،

Shipping،

Final Total.

برای Permission:

Client نمی‌گوید Role چیست.

Server آن را از Session/Token و Database به دست می‌آورد.

برای Ownership:

Client Object ID ارسال می‌کند.

Server بررسی می‌کند Object متعلق به چه Entity است.

این Pattern بسیاری از Business Logic Vulnerabilityها را کاهش می‌دهد.

State Machine صریح بسازید

State را در URL یا Frontend infer نکنید.

State در Server Storage نگهداری شود.

هر Action باید Transition مجاز را بررسی کند.

Transition نامعتبر باید رد شود.

همچنین State Change باید در صورت نیاز Atomic باشد.

عملیات مالی را Atomic کنید

برای Business Operationهای حساس از Database Transaction، Lock یا Conditional Update استفاده کنید.

مثلاً به‌جای:

Read balance
Check balance
Write new balance

می‌توان Operation را با Condition انجام داد که فقط اگر Balance کافی است Update موفق شود.

پیاده‌سازی دقیق به Database بستگی دارد، اما اصل این است:

Check و Change نباید Window ناامن ایجاد کنند.

Idempotency را برای Actionهای حساس در نظر بگیرید

در APIهای Payment یا Order، Request Retry یک اتفاق طبیعی است.

Server باید بتواند بفهمد Request همان عملیات قبلی است.

Idempotency Key باید به Business Operation صحیح Bind شود.

Key نباید اجازه دهد Data Transaction در Retry تغییر کند.

Business Limitها را در Database نیز enforce کنید

اگر Rule بسیار حساس است، تنها Application Check کافی نیست.

Database Constraint، Unique Index یا Transactional Condition می‌تواند لایه دفاع اضافه باشد.

مثلاً Rule:

یک Reward از نوع X برای هر Account

ممکن است بتواند با Unique Constraint تقویت شود.

این کار Race Condition را نیز کاهش می‌دهد.

Authorization را Contextual کنید

سؤال Security Check فقط این نباشد:

isAuthenticated?

یا:

role == admin?

بلکه:

آیا User فعلی،
روی این Object،
در این State،
در این زمان،
این Action را انجام می‌دهد؟

این رویکرد Business Context را وارد Authorization می‌کند.

Rate Limit را Feature-Aware طراحی کنید

Login Rate Limit کافی نیست.

Featureهایی مثل:

Coupon،

Referral،

Reservation،

Password Reset،

Voucher،

Comment،

Search،

Export

ممکن است Limit جداگانه نیاز داشته باشند.

Limit ممکن است بر اساس:

Account،

IP،

Device،

Resource،

Organization،

یا Combination

تعریف شود.

انتخاب باید براساس Threat Model کسب‌وکار باشد.

Automation را از ابتدا در Threat Model در نظر بگیرید

هر Actionی که یک انسان می‌تواند انجام دهد ممکن است Bot هزاران بار انجام دهد.

سؤال مهم:

اگر این Feature ده هزار بار در ساعت استفاده شود چه اتفاقی می‌افتد؟

آیا هزینه ایجاد می‌کند؟

Inventory را قفل می‌کند؟

Notification ارسال می‌کند؟

SMS پولی می‌فرستد؟

Reward تولید می‌کند؟

Spam ایجاد می‌کند؟

OWASP API6:2023 توصیه می‌کند Sensitive Business Flowها شناسایی و برای Abuse خودکار مکانیزم مناسب انتخاب شود.

Rollback Strategy داشته باشید

در Workflow چندمرحله‌ای، Failure نباید State نصفه رها کند.

اگر عملیات 4 مرحله دارد و مرحله 3 Fail شد، مشخص کنید:

آیا 1 و 2 Rollback می‌شوند؟

آیا Job Retry می‌شود؟

آیا State به FAILED می‌رود؟

آیا User می‌تواند دوباره تلاش کند؟

بدون چنین طراحی‌ای Invalid State ایجاد می‌شود.

Logging و Monitoring مخصوص Business Logic

Security Log فقط برای Login Failure نیست.

Business Eventهای حساس نیز باید قابل Audit باشند.

مثلاً:

Coupon Redeemed،

Refund Created،

Permission Changed،

Reservation Cancelled،

Reward Issued،

Payout Requested.

Log باید Context کافی برای Reconstruction حادثه داشته باشد.

همچنین Alert باید روی Patternهای غیرعادی باشد.

مثلاً Userای که در چند دقیقه تعداد غیرمعمولی Reservation ایجاد می‌کند ممکن است از نظر HTTP کاملاً Requestهای معتبر ارسال کند؛ Detection باید Business-Aware باشد.

Threat Modeling مخصوص منطق تجاری

Threat Modeling نباید فقط Diagram شبکه باشد.

برای هر Feature بپرسید:

دارایی چیست؟

User چه Benefitی دریافت می‌کند؟

چگونه می‌تواند Benefit را بیش از حد بگیرد؟

چه Stepی ممکن است Skip شود؟

چه Actionی ممکن است Repeat شود؟

چه Dataای از Client نباید Trust شود؟

اگر Requestها هم‌زمان باشند چه می‌شود؟

اگر External Service Fail شود چه؟

اگر User عمداً خلاف فرضیات Product رفتار کند چه؟

OWASP Top 10:2025 در A06 Insecure Design، Threat Modeling برای Authentication، Access Control، Business Logic و Critical Flowها را از کنترل‌های اصلی پیشگیری معرفی می‌کند.

Business Logic Vulnerability در WordPress

WordPress Core یک CMS عمومی است، اما Pluginها و Themeها می‌توانند Business Workflowهای پیچیده بسازند.

مثلاً:

عضویت،

اشتراک،

رزرو،

فروش فایل،

Wallet،

Referral،

Coupon،

فرم تأیید،

Marketplace.

خطر اصلی اغلب در Custom Code و Plugin Logic ایجاد می‌شود.

یک AJAX Action ممکن است Nonce داشته باشد ولی Business Authorization ناقص باشد.

Nonce اثبات می‌کند Request احتمالاً از Session معتبر آمده است؛ اما لزوماً ثابت نمی‌کند User اجازه Business Action را دارد.

Business Logic در WooCommerce

WooCommerce نمونه‌ای واضح از سیستم Domain-Heavy است.

Order دارای State است.

Coupon Rule دارد.

Stock Management وجود دارد.

Payment Callback وجود دارد.

Refund و Tax و Shipping وجود دارند.

Plugin سفارشی که این Flowها را تغییر می‌دهد باید قواعد را دقیق رعایت کند.

برای مثال هنگام ساخت افزونه تخفیف نباید فقط Price نمایش‌داده‌شده در Cart تغییر کند؛ Server-side Order Total و Payment Amount باید از منبع هماهنگ محاسبه شوند.

همچنین Actionهای Order باید State فعلی را Validate کنند.

Nonce کافی نیست

یکی از سوءبرداشت‌های رایج WordPress این است که:

check_ajax_referer() موفق شد
پس Action امن است.

Nonce بیشتر برای CSRF Protection است.

هنوز باید بررسی شود:

User Authentication،

Capability،

Ownership،

Business State،

Limit،

و Input Validation.

CSRF Protection جایگزین Business Authorization نیست.

Business Logic در REST API وردپرس

در REST Endpoint سفارشی نیز permission_callback اهمیت دارد.

اما حتی Permission Callback عمومی مثل «User لاگین است» ممکن است کافی نباشد.

Endpoint باید بررسی کند آیا User روی Resource مشخص و در وضعیت فعلی اجازه Action دارد.

اشتباهات رایج توسعه‌دهندگان در منطق تجاری

یکی از بزرگ‌ترین اشتباهات این است که UI به‌عنوان Security Control در نظر گرفته شود.

اشتباه دیگر اعتماد به Hidden Field و JavaScript Validation است.

بعضی تیم‌ها نیز Limit را فقط با Rate Limiter پیاده می‌کنند درحالی‌که Business Limit متفاوت است.

برخی سیستم‌ها State را فقط از Page Flow استنباط می‌کنند و State Machine Server-Side ندارند.

گاهی Price، Discount یا Role از Client پذیرفته می‌شود.

در سیستم‌های مالی نیز اجرای Check و Update در دو Operation جدا باعث Race Condition می‌شود.

یکی دیگر از خطاها این است که Business Rule فقط روی Endpoint اصلی اعمال شود و نسخه API قدیمی یا Admin Endpoint همان Action را بدون Rule کامل انجام دهد.

چک‌لیست دفاعی جلوگیری از Business Logic Vulnerability

چگونه یک Business Logic Vulnerability را گزارش کنیم؟

گزارش نباید فقط بنویسد:

Business logic issue exists.

باید Business Rule مورد انتظار را مشخص کند.

مثلاً:

Rule:
هر Coupon باید حداکثر یک بار برای هر Account قابل استفاده باشد.

سپس رفتار واقعی بیان شود:

Observed Behavior:
Backend امکان ثبت چند Redemption مستقل را می‌پذیرد.

بعد Impact:

Impact:
User می‌تواند Benefit بیشتری از مقدار طراحی‌شده دریافت کند.

و در نهایت Root Cause و Remediation:

Root Cause:
Usage Limit فقط در Frontend کنترل شده است.

Remediation:
Limit را در Server و Transaction مربوطه enforce کنید
و در صورت مناسب بودن با Database Constraint تقویت کنید.

این گزارش برای Developer بسیار مفیدتر از برچسب کلی «Business Logic» است.

آیا Business Logic Vulnerability همیشه Critical است؟

خیر.

Severity کاملاً به Business Impact بستگی دارد.

اگر User بتواند یک Welcome Message را دو بار دریافت کند، احتمالاً Risk پایین است.

اگر همان ضعف باعث شود Transfer مالی دو بار انجام شود، موضوع بسیار جدی است.

برای Severity باید موارد زیر بررسی شوند:

ارزش Asset،

میزان Benefit،

تعداد Userهای قابل تأثیر،

نیاز یا عدم نیاز به Authentication،

قابلیت Automation،

مقیاس Abuse،

قابلیت تکرار،

اثر مالی،

اثر روی Integrity،

و Detection Difficulty.

Business Impact با Technical Impact فرق دارد

ممکن است هیچ Serverی Compromise نشود.

هیچ Shellی اجرا نشود.

هیچ Databaseای Dump نشود.

اما Business میلیون‌ها تومان ضرر کند.

مثلاً Bot موجودی محصول محدود را رزرو کند و User واقعی نتواند خرید انجام دهد.

OWASP API6 نیز اشاره می‌کند که Business Flow Abuse ممکن است Impact فنی سنتی زیادی نداشته باشد اما Business Impact قابل توجهی ایجاد کند.

این نکته در ارزیابی Severity بسیار مهم است.

Business Logic و Secure by Design

اصلاح Business Logic بعد از Production معمولاً سخت‌تر از Fix کردن یک Output Encoding ساده است.

چون ممکن است Database Schema، Workflow، API Contract و Product Requirement همگی نیاز به تغییر داشته باشند.

به همین دلیل Secure by Design اهمیت دارد.

OWASP Top 10:2025 بین Insecure Design و Insecure Implementation تفاوت قائل می‌شود.

یک Design امن ممکن است Bad Implementation داشته باشد.

اما اگر Design از ابتدا Control موردنیاز را تعریف نکرده باشد، اجرای بی‌نقص همان Design نیز امن نخواهد بود.

Abuse Case چیست؟

Use Case توضیح می‌دهد User عادی چه کاری انجام می‌دهد.

مثلاً:

User Coupon را اعمال می‌کند.

Abuse Case می‌پرسد:

اگر User Coupon را چند بار اعمال کند چه؟

اگر دو Coupon ناسازگار را ترکیب کند چه؟

اگر Coupon منقضی باشد ولی Request مستقیم ارسال شود چه؟

اگر Request هم‌زمان ارسال شود چه؟

اگر Coupon روی Order دیگری Replay شود چه؟

هدف Abuse Case فکر کردن از زاویه کاربر غیرهمکار است.

Misuse Case و تست امنیت

Misuse Case نیز سناریویی است که Feature در روشی غیر از هدف طراحی‌شده استفاده می‌شود.

OWASP WSTG Business Logic Testing را بسیار نزدیک به Functional Testing و Finite-State Testing می‌داند و توصیه می‌کند Tester Misuse Caseها را براساس Process کامل طراحی کند.

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

QA Business Requirement را می‌شناسد.

AppSec Abuse Patternها را می‌شناسد.

ترکیب این دو بسیار مؤثر است.

Business Logic در CI/CD چگونه تست شود؟

پس از تعریف Invariantها، تست خودکار ایجاد کنید.

مثلاً:

OrderTotal never becomes negative.

UsedCoupon cannot return to UNUSED
without an explicit administrative rollback.

A paid transaction cannot be executed twice.

A SHIPPED order cannot transition back to PENDING_PAYMENT.

این Testها در هر Deployment اجرا شوند.

Regression اهمیت زیادی دارد، زیرا Business Flow با اضافه شدن Feature جدید ممکن است ناخواسته شکسته شود.

Monitoring بعد از انتشار

Secure Design احتمال Abuse را کاهش می‌دهد اما Detection همچنان ضروری است.

Business Metricها می‌توانند Signal امنیتی باشند.

مثلاً:

نرخ غیرعادی Coupon Redemption،

Refund Rate غیرمعمول،

Account Creation زیاد،

Reservation Cancellation بالا،

Reward Issuance Spike،

Payment Retry غیرمعمول.

Security Monitoring باید با Business Analytics ارتباط داشته باشد.

گاهی بهترین Detector یک SIEM Rule سنتی نیست، بلکه یک Business KPI غیرعادی است.

اگر Business Logic Vulnerability پیدا شد چه کنیم؟

اول Rule واقعی را با Product Owner مشخص کنید.

گاهی رفتار عجیب از دید Tester ممکن است واقعاً Feature موردنظر کسب‌وکار باشد.

پس از تأیید Rule، تمام Entry Pointها را Inventory کنید.

مشخص کنید Action از کجا قابل فراخوانی است:

Web،

API،

Mobile،

Webhook،

Admin.

بعد State و Data Flow را بررسی کنید.

Fix فقط روی یک Controller ممکن است کافی نباشد.

در ادامه Regression Test ایجاد کنید تا مشکل دوباره برنگردد.

اگر Vulnerability مالی بوده، Logها باید برای Abuse قبلی بررسی شوند.

Incident Response در Business Logic Abuse

Business Logic Abuse همیشه Log خطا تولید نمی‌کند.

Requestها ممکن است HTTP 200 داشته باشند.

تمام Queryها معتبر باشند.

User نیز Authentication موفق داشته باشد.

بنابراین Incident Response باید Business Eventها را بررسی کند.

مثلاً:

چه Userهایی Benefit دریافت کرده‌اند؟

چه Accountهایی Pattern مشابه دارند؟

از چه زمانی Feature قابل Abuse بوده؟

Financial Exposure چقدر است؟

آیا باید Reward یا Credit معکوس شود؟

آیا Token یا Account نیاز به Block دارد؟

این Incidentها معمولاً نیازمند همکاری AppSec، Product، Finance و Fraud Team هستند.

سؤالات متداول درباره Business Logic Vulnerability

Business Logic Vulnerability چیست؟

Business Logic Vulnerability ضعفی است که در آن Application قوانین و Workflow مورد انتظار کسب‌وکار را به‌درستی enforce نمی‌کند. در نتیجه User می‌تواند از قابلیت‌های عادی سیستم در Sequence، State، مقدار یا تعداد دفعاتی استفاده کند که کسب‌وکار انتظار نداشته است.

آیا Business Logic Vulnerability همان Insecure Design است؟

کاملاً مترادف نیستند، اما ارتباط نزدیکی دارند. OWASP Top 10:2025 نقص‌های Business Logic را یکی از نمونه‌های A06 Insecure Design می‌داند، زیرا بسیاری از آنها از Requirement یا Design ناقص ناشی می‌شوند.

CWE مربوط به Business Logic Vulnerability چیست؟

CWE-840 یک Category با عنوان Business Logic Errors است و برای Mapping مستقیم Vulnerability واقعی نباید استفاده شود. بسته به Root Cause ممکن است CWE-841 برای Workflow Sequence، CWE-837 برای Actionای که فقط یک بار باید انجام شود یا CWE دقیق دیگری مناسب باشد.

چرا Scannerها Business Logic Vulnerability را سخت پیدا می‌کنند؟

زیرا Scanner معمولاً Business Requirement سیستم را نمی‌داند. یک Request ممکن است از نظر HTTP، Syntax، Authentication و Database کاملاً معتبر باشد ولی از نظر Business Rule نامعتبر باشد. تشخیص این موضوع به شناخت Domain و Workflow نیاز دارد.

آیا Frontend Validation کافی است؟

خیر. Frontend برای UX مناسب است اما Security Control نهایی نیست. هر Rule مهم باید در Backend و نزدیک Business Operation enforce شود.

آیا Hidden Field قابل اعتماد است؟

خیر. هر داده‌ای که از Client می‌آید قابل تغییر است. Hidden Input، JavaScript State، Mobile App Parameter و Client-side Price همگی باید در Server مجدداً بررسی شوند.

آیا Business Logic Vulnerability همیشه نیازمند Payload است؟

خیر. بسیاری از این ضعف‌ها فقط با استفاده از Requestهای کاملاً معتبر در ترتیب، تعداد یا زمان‌بندی غیرمنتظره ایجاد می‌شوند.

State Machine چه کمکی می‌کند؟

State Machine مشخص می‌کند هر Workflow چه Stateهایی دارد و از هر State چه Transitionهایی مجاز هستند. Backend می‌تواند قبل از انجام Action، State فعلی را بررسی و Transition نامعتبر را Reject کند.

Race Condition چه ارتباطی با Business Logic دارد؟

اگر دو Request هم‌زمان بتوانند یک Invariant مانند Balance، Stock یا Usage Limit را دور بزنند، Race Condition باعث Business Logic Violation می‌شود. عملیات Check-Then-Act حساس باید Atomic باشد.

Idempotency Key چیست؟

Idempotency Key شناسه‌ای است که Server از آن برای تشخیص اجرای تکراری یک Business Operation استفاده می‌کند. در عملیات‌هایی مانند Payment و Order Creation می‌تواند از ایجاد نتیجه چندباره در اثر Retry جلوگیری کند.

Rate Limit برای جلوگیری از Business Logic Abuse کافی است؟

خیر. Rate Limit بخشی از دفاع است. Business Limit ممکن است مستقل از زمان باشد؛ مثلاً هر User فقط یک بار در طول عمر Account حق دریافت Reward داشته باشد.

Business Logic Vulnerability در WordPress ممکن است رخ دهد؟

بله. Pluginها و Themeهایی که Workflowهایی مثل Payment، Subscription، Coupon، Booking، Wallet یا Referral ایجاد می‌کنند می‌توانند Business Logic Flaw داشته باشند. Nonce یا Authentication به‌تنهایی کافی نیست و Capability، Ownership، State و Business Rule نیز باید بررسی شوند.

Business Logic Vulnerability در WooCommerce چگونه ایجاد می‌شود؟

معمولاً در Custom Pluginها یا Integrationهایی که Order State، Coupon، Payment، Stock، Credit یا Refund را تغییر می‌دهند. Ruleهای WooCommerce و Business Rule سفارشی باید در Backend و تمام Entry Pointها یکسان enforce شوند.

بهترین روش جلوگیری از Business Logic Vulnerability چیست؟

Business Ruleها را صریح تعریف کنید، مقادیر حساس را Server-Side محاسبه کنید، Workflowها را State Machine کنید، Authorization را Contextual انجام دهید، عملیات حساس را Atomic و Idempotent طراحی کنید، Limits را در Backend enforce کنید و Threat Modeling و Misuse Testing داشته باشید.

آیا WAF می‌تواند Business Logic Vulnerability را متوقف کند؟

معمولاً نه به‌عنوان کنترل اصلی. Request ممکن است کاملاً Valid باشد و هیچ Signature مخربی نداشته باشد. WAF می‌تواند لایه مکمل برای Rate Limit یا Detection باشد اما Business Rule باید داخل Application enforce شود.

جمع‌بندی

Business Logic Vulnerability یکی از مهم‌ترین و در عین حال سخت‌ترین دسته‌های ضعف در امنیت وب است، زیرا Application در بسیاری از موارد از نظر فنی کاملاً درست کار می‌کند.

هیچ SQL Injection وجود ندارد.

هیچ XSS وجود ندارد.

Request نیز ممکن است کاملاً معتبر باشد.

اما User از یک قابلیت مشروع در حالتی استفاده می‌کند که Product و Developer انتظار آن را نداشته‌اند.

ریشه اصلی مشکل معمولاً یک فرض ناگفته است.

توسعه‌دهنده فرض می‌کند User مراحل UI را به ترتیب طی می‌کند.

فرض می‌کند Button غیرفعال‌شده دوباره قابل استفاده نیست.

فرض می‌کند Request فقط یک بار می‌رسد.

فرض می‌کند دو Request هم‌زمان نمی‌آیند.

فرض می‌کند Price ارسالی از Frontend تغییر نمی‌کند.

فرض می‌کند User از Feature بیش از حد استفاده نخواهد کرد.

امنیت زمانی ایجاد می‌شود که این فرض‌ها به Ruleهای صریح و قابل enforce تبدیل شوند.

Workflowهای چندمرحله‌ای باید State Machine Server-Side داشته باشند.

هر Transition باید براساس State فعلی Validate شود.

قیمت، Ownership، Permission و سایر Security-Relevant Valueها باید از Source معتبر Server-Side تعیین شوند.

Actionهای مالی و Check-Then-Act باید Atomic باشند.

Retryها نباید باعث اجرای دوباره Transaction شوند و برای Operationهای مناسب باید Idempotency در نظر گرفته شود.

Limitهای Business مانند Coupon، Trial، Reward و Reservation باید مستقل از UI در Backend enforce شوند.

Sensitive Business Flowها باید برای Automation و Bot Abuse نیز Threat Model شوند؛ موضوعی که OWASP API Security Top 10:2023 در API6 Unrestricted Access to Sensitive Business Flows روی آن تأکید می‌کند.

همچنین باید میان CWE-840 و CWEهای قابل نگاشت تفاوت گذاشت. CWE-840 صرفاً Category مربوط به Business Logic Errors است و MITRE توصیه می‌کند برای Vulnerability واقعی Root Cause دقیق، مانند CWE-841 برای Enforcement نامناسب Workflow، انتخاب شود.

در OWASP Top 10:2025، Business Logic Flawها ارتباط مستقیمی با A06 Insecure Design دارند. OWASP توصیه می‌کند Business Logic و Critical Flowها از مرحله Design وارد Threat Modeling، User Story و Unit/Integration Testing شوند.

بنابراین مهم‌ترین پرسش هنگام بررسی امنیت منطق تجاری این نیست:

«آیا User یک Payload مخرب وارد می‌کند؟»

پرسش مهم‌تر این است:

«اگر User کاملاً آگاهانه، متقلبانه و برخلاف فرضیات ما از قابلیت‌های قانونی سیستم استفاده کند، آیا Backend همچنان تمام قوانین واقعی کسب‌وکار را enforce می‌کند؟»

پاسخ دقیق به همین سؤال بسیاری از Business Logic Vulnerabilityهای خطرناک را قبل از رسیدن به Production آشکار می‌کند.