امنیت فروشگاه اینترنتی: باگ‌های منطقی که اسکنر پیدا نمی‌کند

بیشتر آسیب‌پذیری‌هایی که به یک فروشگاه اینترنتی پول تحمیل می‌کنند، تزریق SQL یا XSS نیستند. آن‌ها باگ‌های منطق کسب‌وکار هستند: هر درخواست به‌تنهایی کاملاً قانونی است، اما ترتیب یا مقدارش چیزی را ممکن می‌کند که هرگز قرار نبوده ممکن باشد — خرید با قیمت صفر، استفاده‌ی چندباره از یک کد تخفیف، یا ثبت سفارش موفق بدون پرداخت واقعی. هیچ اسکنری این‌ها را پیدا نمی‌کند و همین است که امنیت سایت فروشگاهی را به یک کار دستی و درک‌محور تبدیل می‌کند. این مقاله الگوهای واقعی را با تمرکز بر بازار ایران — و مخصوصاً مسئله‌ی تأیید کالبک درگاه پرداخت — توضیح می‌دهد.

چرا امنیت فروشگاه با امنیت یک سایت معمولی متفاوت است

در یک سایت محتوایی، بدترین اتفاق افشای داده یا دیفیس است. در یک فروشگاه، مهاجم می‌تواند مستقیماً پول شما را ببرد — و بدون شکستن هیچ کنترل امنیتی کلاسیکی. سه ویژگی این تفاوت را می‌سازد:

• جریان‌های چندمرحله‌ای با وضعیت. سبد، حمل‌ونقل، تخفیف، پرداخت و تأیید یک ماشین حالت است؛ هرجا وضعیت هست، امکان رسیدن به وضعیت غیرمجاز هم هست.
• یکپارچگی با سرویس‌های بیرونی. هر یکپارچه‌سازی یک مرز اعتماد است، و مرز اعتمادِ بدون راستی‌آزمایی یعنی آسیب‌پذیری.

OWASP این دسته را در A06:2025 طراحی ناامن قرار می‌دهد و جمله‌ی کلیدی‌اش اینجا کاملاً مصداق دارد: «یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی نمی‌تواند اصلاح کند.» اگر جریان پرداخت شما از پایه به داده‌ی کلاینت اعتماد کند، هیچ مقدار اعتبارسنجی ورودی آن را نجات نمی‌دهد.

دستکاری قیمت، تعداد و مقادیر محاسباتی

ساده‌ترین و همچنان یکی از رایج‌ترین کلاس‌ها. ریشه‌ی همه‌ی حالت‌ها یک چیز است: مقداری که باید در سرور محاسبه شود، از کلاینت پذیرفته می‌شود.

الگوهای عملی

• قیمت در فیلد مخفی فرم. اگر price در بدنه‌ی درخواست افزودن به سبد وجود دارد و سرور آن را استفاده می‌کند، آسیب‌پذیری قطعی است.
• تعداد منفی. quantity=-1 در سبدی که مجموع را با ضرب محاسبه می‌کند، می‌تواند مجموع را کاهش دهد یا حتی منفی کند. حالت‌های مشابه: عدد اعشاری، عدد بسیار بزرگ که سرریز می‌شود، و مقدار غیرعددی.
• دستکاری مبلغ در مرحله‌ی انتقال به درگاه. اگر مبلغ نهایی از پارامتر درخواست ساخته شود و در سمت سرور با مجموع سبد مقایسه نشود، مهاجم مبلغ کمتری به درگاه می‌فرستد.
• گردکردن و اعشار. اختلاف گردکردن بین مراحل محاسبه‌ی تخفیف می‌تواند به سود مهاجم انباشته شود.

POST /cart/add
{ "product_id": 4471, "quantity": 1, "price": 2450000 }

// هر فیلدی جز شناسه و تعداد باید در سرور بازمحاسبه شود

اصلاح

• از کلاینت فقط شناسه و تعداد را بپذیرید. قیمت، تخفیف، مالیات و هزینه‌ی ارسال را همیشه از منبع معتبر سمت سرور بخوانید.
• بررسی معقول‌بودن در لایه‌ی نهایی: پیش از ثبت سفارش، مجموع را مستقل بازمحاسبه کنید و با مبلغ پرداخت‌شده مقایسه کنید. این «بررسی پایانی» بسیاری از حالت‌های ناشناخته را هم می‌گیرد.
• سفارش‌های با مبلغ غیرعادی (خیلی کم، منفی، یا بسیار بزرگ) را ثبت لاگ و هشدار کنید — این همان کاربرد عملی A09:2025 است.

سوءاستفاده از کد تخفیف: انباشتگی و استفاده‌ی مجدد

کدهای تخفیف قواعد کسب‌وکاری پیچیده‌ای دارند و هر قاعده‌ی نانوشته یک آسیب‌پذیری است. الگوهای واقعی:

• انباشتگی (Stacking): ارسال چند کد تخفیف در یک درخواست، یا ارسال متوالی چند کد که هر بار روی مبلغ کاهش‌یافته‌ی قبلی اعمال می‌شود. اگر منطق «فقط یک کد» را در UI پیاده کرده‌اید و نه در سرور، این کار می‌کند.
• استفاده‌ی مجدد از کد یک‌بارمصرف: با درخواست‌های موازی (بخش شرایط رقابتی)، یا با اعمال کد سپس حذف محصول و افزودن مجدد، یا با ثبت سفارش‌های موازی از یک حساب.
• حذف نکردن تخفیف پس از تغییر سبد: کد روی سبد پر اعمال می‌شود، اقلام حذف می‌شوند و مبلغ تخفیف باقی می‌ماند — گاهی بیشتر از مبلغ سبد.
• حدس زدن کدها. کدهای الگودار (OFF10) قابل فهرست‌سازی‌اند؛ اندپوینت اعتبارسنجی بدون نرخ‌بندی یک اوراکل حدس است.

اصلاح

• قواعد تخفیف را صریح و در سمت سرور مدل کنید: سازگاری کدها، سقف تخفیف، و حداقل مبلغ سبد.
• مصرف کد را با محدودیت یکتایی در پایگاه‌داده ثبت کنید تا در شرایط موازی هم دو بار ثبت نشود.
• کدها را تصادفی تولید و اندپوینت اعتبارسنجی را نرخ‌بندی کنید.
• سقف تخفیف را در لایه‌ی پرداخت هم بررسی کنید؛ مبلغ نهایی هرگز نباید منفی شود.

پرش از مراحل خرید و دور زدن گردش کار

فرایند خرید یک ماشین حالت است: سبد → آدرس → روش ارسال → پرداخت → تأیید. اگر انتقال‌های مجاز در سمت سرور اعمال نشوند، مهاجم می‌تواند مرحله‌ای را حذف یا وضعیتی را جعل کند.

الگوهای رایج

• فراخوانی مستقیم اندپوینت تأیید سفارش بدون طی مرحله‌ی پرداخت؛ اگر order/complete وضعیت پرداخت را بررسی نکند، سفارش بدون پرداخت ثبت می‌شود.
• تغییر سبد بین اعتبارسنجی پرداخت و ثبت سفارش: مبلغ برای سبد کوچک پرداخت می‌شود و بعد اقلام گران اضافه می‌شوند.
• استفاده‌ی مجدد از یک شناسه‌ی پرداخت موفق برای چند سفارش، وقتی شناسه‌ی تراکنش یک‌بارمصرف نیست و به سفارش خاصی گره نخورده.

اصلاح

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

تأیید کالبک درگاه پرداخت — مخرب‌ترین الگو در بازار ایران

اگر از این مقاله فقط یک بخش را بخوانید، همین باشد. الگوی خطا در فروشگاه‌های ایرانی به‌طور نگران‌کننده‌ای تکرار می‌شود و اثرش مستقیماً مالی است.

جریان درست پرداخت

1. سرور شما مبلغ را خودش محاسبه می‌کند و درخواست ایجاد تراکنش را به درگاه می‌فرستد؛ درگاه یک شناسه/توکن تراکنش برمی‌گرداند.
2. کاربر به صفحه‌ی درگاه هدایت می‌شود و پرداخت را انجام می‌دهد.
3. درگاه کاربر را به آدرس بازگشت (callback) شما برمی‌گرداند، همراه با پارامترهایی درباره‌ی نتیجه.
4. سرور شما یک درخواست مستقل و سرور به سرور به API درگاه می‌زند و تراکنش را وریفای می‌کند. فقط پاسخ این درخواست است که «پرداخت موفق» را اثبات می‌کند.
5. سرور بررسی می‌کند مبلغ تأییدشده با مبلغ سفارش برابر است، تراکنش قبلاً استفاده نشده است، و شناسه‌ی تراکنش به همین سفارش تعلق دارد.
6. سپس و فقط سپس، سفارش را پرداخت‌شده علامت می‌زند.

الگوهای خطا که دیده می‌شوند

• اعتماد به پارامترهای آدرس بازگشت. اگر کد شما با دیدن ?status=OK یا Status=success در URL بازگشت، سفارش را تأیید می‌کند، مهاجم می‌تواند خودش همان آدرس را با همان پارامترها باز کند. این کامل‌ترین شکل «اعتماد به داده‌ی کلاینت» است.
• وریفای نکردن مبلغ. تراکنش واقعاً موفق بوده، اما برای مبلغ بسیار کمتر؛ اگر مبلغ تأییدشده با مبلغ سفارش مقایسه نشود، مهاجم با هزار تومان سفارش چند میلیونی ثبت می‌کند.
• یکتا نبودن تراکنش: یک شناسه‌ی موفق برای چند سفارش، چون رکورد مصرف با محدودیت یکتایی محافظت نشده.
• کالبک بدون احراز اصالت. اندپوینت اعلان پرداخت (IPN/webhook) بدون بررسی امضا و بدون وریفای متقابل، هر بدنه‌ای را می‌پذیرد.
• شرایط رقابتی روی کالبک: دو درخواست هم‌زمان، در نبود قفل یا محدودیت یکتایی، دو بار کیف پول را شارژ می‌کند.

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

شرایط رقابتی روی موجودی، کیف پول و کد تخفیف

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

نقاط پرخطر

• موجودی انبار: ده درخواست موازی برای آخرین کالا؛ همه «۱ عدد موجود است» را می‌بینند و همه ثبت می‌شوند.
• کیف پول و اعتبار: دو برداشت موازی از موجودی ۱۰۰ هزار تومان، هر دو کامل انجام می‌شوند. همین الگو در بازگشت وجه هم هست.
• هر شمارنده‌ای با الگوی بررسی‌سپس‌افزایش: امتیاز وفاداری، محدودیت خرید، شمارنده‌ی تلاش.

چرا «از راه اینترنت عملی نیست» درست نیست

باور قدیمی این بود که برای بهره‌برداری از شرایط رقابتی باید به سرور نزدیک بود، چون نوسان شبکه پنجره را از بین می‌برد. حمله‌ی تک‌بسته‌ای (single-packet attack) این فرض را باطل کرده: با مالتی‌پلکسینگ HTTP/2 می‌توان چندین درخواست کامل را در یک بسته‌ی TCP بسته‌بندی کرد تا هم‌زمان برسند. پژوهش PortSwigger نشان داده با این روش حدود بیست تا سی درخواست در پنجره‌ای زیر یک میلی‌ثانیه اجرا می‌شود — حتی در ارتباطات قاره‌ای. در Burp Repeater با گروه‌بندی درخواست‌ها و «Send group in parallel» انجام می‌شود.

اصلاح — و اشتباه رایج در اصلاح

• به‌روزرسانی اتمی و شرطی در پایگاه‌داده بهترین راه‌حل است:

UPDATE wallets SET balance = balance - 50000
WHERE user_id = ? AND balance >= 50000;
-- سپس تعداد سطرهای تغییریافته را بررسی کنید؛ صفر یعنی موجودی کافی نبود

• قفل سطری (SELECT ... FOR UPDATE) یا تراکنش با سطح ایزوله‌سازی مناسب روی رکورد موجودی.
• محدودیت یکتایی به‌عنوان تور ایمنی برای مصرف کد تخفیف و شناسه‌ی تراکنش، و کلید ایدمپوتنسی برای پرداخت و ثبت سفارش.
• اشتباه رایج: قفل در سطح برنامه (mutex). روی چند نمونه‌ی افقی سرور کار نمی‌کند و رایج‌ترین «اصلاحِ ناکارآمد» است؛ اتمی‌سازی در پایگاه‌داده یا قفل توزیع‌شده لازم است.

IDOR روی سفارش و فاکتور، و سوءاستفاده از بازگشت وجه

IDOR روی اندپوینت‌های سفارش

IDOR رایج‌ترین یافته‌ی افشای داده در فروشگاه‌هاست. الگو: اندپوینتی که شناسه‌ی سفارش را می‌گیرد و بررسی نمی‌کند این سفارش به کاربر درخواست‌کننده تعلق دارد.

• مشاهده‌ی سفارش و فاکتور (/invoice/download?id=10432). داده‌ی افشاشده معمولاً کامل است: نام، آدرس، موبایل، اقلام و مبلغ.
• API پنل کاربری که در نسخه‌ی وب بررسی مالکیت دارد و در نسخه‌ی موبایل ندارد.
• عملیات نوشتن: لغو یا تغییر آدرس سفارش دیگری.

و یک تذکر مهم: UUID این مشکل را حل نمی‌کند. شناسه‌ی غیرقابل‌حدس هزینه‌ی کشف را بالا می‌برد اما بررسی مجوزی اضافه نمی‌کند، و UUIDها از پاسخ اندپوینت‌های دیگر و از لینک‌های اشتراکی نشت می‌کنند. اصلاح درست: مالکیت را در همان کوئری خواندن اعمال کنید (WHERE id = ? AND user_id = ?).

سوءاستفاده از بازگشت وجه و مرجوعی

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

• بازگشت وجه برای سفارشی که قبلاً بازگشت وجه شده (نبود بررسی وضعیت).
• بازگشت وجه بیشتر از مبلغ پرداخت‌شده، یا بازگشت‌های جزئیِ چندباره که مجموعشان از کل بیشتر می‌شود.
• شرایط رقابتی روی خودِ بازگشت وجه: دو درخواست موازی، دو بار واریز.

اصلاح: هر عملیات مالی باید در برابر وضعیت فعلی سفارش اعتبارسنجی شود، مجموع بازگشت‌ها سقف داشته باشد، عملیات ایدمپوتنت و در تراکنش پایگاه‌داده انجام شود، و هر رخداد مالی لاگ تغییرناپذیر داشته باشد.

داده‌ی کارت، دامنه‌ی PCI DSS و جدول کنترل‌ها

سیاست درست درباره‌ی داده‌ی کارت یک جمله است: به آن دست نزنید. هرچه داده‌ی کارت کمتر از سیستم شما بگذرد، دامنه‌ی الزامات و ریسک کمتر است.

• هرگز شماره‌ی کارت، CVV یا تاریخ انقضا را ذخیره نکنید. در مدل رایج بازار ایران داده‌ی کارت فقط در صفحه‌ی درگاه وارد می‌شود و به سرور شما نمی‌رسد؛ این مدل را با فرم واسط خودتان جایگزین نکنید.
• داده‌ی کارت را در لاگ ننویسید. این یکی از رایج‌ترین راه‌های نشت است و در CWE-532 (درج اطلاعات حساس در فایل لاگ) دسته‌بندی می‌شود. لاگ کامل بدنه‌ی درخواست در جریان پرداخت را غیرفعال کنید.
• PCI DSS نسخه‌ی جاری v4.0.1 است (ژوئن ۲۰۲۴) و الزامات آینده‌دار v4.x از ۳۱ مارس ۲۰۲۵ اجباری شده‌اند. بند 11.4 تست نفوذ دوره‌ای (حداکثر هر ۱۲ ماه و پس از تغییر مهم) و آزمون مجدد پس از رفع را الزامی می‌کند.

برنامه‌ی آزمون: چه چیزی را چطور بررسی کنیم

همه‌ی موارد این مقاله یک ویژگی مشترک دارند: آزمون دستی لازم است. برنامه‌ی عملی:

1. جریان‌ها را نقشه‌برداری کنید: یک خرید کامل انجام دهید و همه‌ی درخواست‌ها را با Burp Suite یا Caido ثبت کنید.
2. هر پارامتر محاسباتی را دستکاری کنید و ترتیب مراحل را بشکنید: مرحله‌ی بعد را بدون مرحله‌ی قبل صدا بزنید و به مرحله‌ی قبل برگردید و داده را تغییر دهید.
3. جریان پرداخت را با دقت مضاعف بررسی کنید: وریفای سرور به سرور، مقایسه‌ی مبلغ، و یک‌بارمصرف بودن تراکنش.
4. درخواست‌های موازی بفرستید روی موجودی، کیف پول، کد تخفیف و بازگشت وجه.
5. آزمون کنترل دسترسی با دو حساب: درخواست‌های حساب اول را با نشست حساب دوم بازپخش کنید.
6. مدل‌سازی تهدید پیش از توسعه‌ی قابلیت‌های مالی جدید — ارزان‌ترین نقطه‌ی مداخله.

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

پرسش‌های متداول

WRITTEN BY

علیرضا کیا

کارشناس وب و موبایل

متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.

LinkedIn ↗درباره تیم ←