تصور کنید هزاران ربات با شناسه‌های مختلف، هر لحظه سبد خرید فروشگاه شما را پر و خالی می‌کنند تا سرور را به زانو درآورند. اگر هنوز برای امنیت سایت خود به لیست سیاه IPها تکیه می‌کنید، باید بدانید که مهاجمان اکنون راهی برای دور زدن این سد پیدا کرده‌اند.
در ۵ اکتبر ۲۰۲۶، شرکت Zologic جزئیات مقابله با یک حمله توزیع‌شده را منتشر کرد که در آن ۸۰۹۶ آدرس IP منحصربه‌فرد یک فروشگاه WooCommerce را هدف قرار داده بودند. این حمله با هدف تخلیه منابع سرور از طریق تغییرات بی‌وقفه و بدون وضعیت (Stateless) در سبد خرید انجام می‌شد. طبق گزارش Zologic، سیستم‌های امنیتی سنتی که بر اساس اعتبار IP یا رشته‌های User-Agent عمل می‌کنند، در برابر چرخش سریع آدرس‌ها کاملاً ناتوان هستند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن و زیرساخت‌های وب اشاره کردیم، تکیه بر شناسه‌های ثابت در عصر اتوماسیون پیشرفته دیگر پاسخگو نیست. این چالش دقیقاً همان نقطه‌ای است که تجارت الکترونیک مدرن با آن روبروست: چگونه بات‌نت‌ها را متوقف کنیم اما درهای فروشگاه را برای عامل‌های هوش مصنوعی (AI Agents) — که شبیه به ربات‌ها رفتار می‌کنند اما مشتریانی واقعی هستند — باز نگه داریم؟
کالبدشکافی حمله
Zologic ابتدا متوجه این ناهنجاری از طریق گوگل آنالیتیکس شد. ترافیک به‌شدت افزایش یافته بود و تعداد کاربران فعال و جدید رشد چشمگیری داشت، اما نرخ تعامل (Engagement) و درآمد روی صفر باقی مانده بود. الگوی ترافیک فریبنده بود؛ در نگاه اول شبیه به رشد ارگانیک به نظر می‌رسید، اما رفتار کاربران کاملاً غیرانسانی بود.
بررسی لاگ‌های سرور نشان داد که هزاران درخواست به آدرس‌های حاوی ?add-to-cart=... ارسال شده و بلافاصله پس از آن، درخواستی برای صفحه سبد خرید ثبت می‌شد. در بسیاری از موارد، درخواست دوم تنها یک یا دو ثانیه پس از درخواست اول می‌رسید.
مهاجمان برای تقلید از مرورگرهای واقعی، از یک امضای ثابت Chrome/150 استفاده می‌کردند. به طور دقیق، رشته User-Agent به این صورت بود: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36.
از آنجایی که شبکه مهاجمان سریع‌تر از آن بود که سیستم‌های اعتبارسنجی بتوانند پاسخ دهند، ابزارهای سنتی مانند Fail2ban بی‌اثر بودند. Zologic از میان لاگ‌های موجود، ۸۰۹۶ آدرس IP منحصربه‌فرد را استخراج کرد که از این امضای خاص استفاده می‌کردند. نمونه‌برداری از ASNها نشان داد که ترافیک از زیرساخت‌های مختلف میزبانی و پروکسی، از جمله چندین شبکه میزبانی شناخته شده، ارسال می‌شد. با این حال، مسدود کردن بر اساس ASN یا User-Agent رد شد؛ زیرا User-Agent تنها یک سیگنال است و نه یک هویت، و مسدود کردن جهانی Chrome 150 یک تصمیم امنیتی نادرست می‌بود.
رفع شکاف در چرخه حیات وردپرس
در طول تحقیقات، Zologic یک نقص بحرانی در نحوه تعامل سیستم‌های ضد-ربات با چرخه حیات وردپرس شناسایی کرد. آن‌ها مشاهده کردند که خزنده‌های شناخته‌شده‌ای مانند SERankingBacklinksBot ،MJ12bot و Reflectionbot در حال ارسال درخواست به عملیات سبد خرید هستند.
آن‌ها دریافتند که تشخیص درست یک ربات، اگر اجرای دستور مسدودسازی خیلی دیر اتفاق بیفتد، هیچ کمکی نمی‌کند. WooCommerce درخواست‌های قدیمی افزودن به سبد خرید را در قلاب (Hook) wp_loaded پردازش می‌کند. اگر بررسی امنیتی بعد از این نقطه رخ دهد، عملیات گران‌قیمت تغییر وضعیت در دیتابیس پیش از مسدود شدن ربات اجرا شده است.
برای حل این مشکل، تیم فنی یک اکشن با اولویت ۱ تعریف کرد: add_action( 'wp_loaded', array( __CLASS__, 'observe_request' ), 1 );. با انتقال اجرای امنیتی به اولویت ۱، آن‌ها تضمین کردند که بررسی پیش از هرگونه تغییر در وضعیت (Mutation) رخ دهد. تست‌های کنترل‌شده تایید کرد که MJ12bot ،Reflectionbot و SERanking همگی با خطای ۴۰۳ مواجه شدند، در حالی که مرورگرهای عادی بدون مشکل در جریان استاندارد ووکامرس پیش رفتند.
پیاده‌سازی اثبات مبتنی بر وضعیت
به جای پرسش «آیا این IP یک ربات است؟»، Zologic پرسید «آیا این کلاینت وضعیت مورد نیاز را ایجاد کرده است؟». آن‌ها لایه‌ای ایجاد کردند که پیش از اجازه برای هر تغییر در سبد خرید، یک اثبات امضا شده و کوتاه‌مدت را می‌طلبد. این کار اقتصاد حمله را تغییر می‌دهد، زیرا عملیات کورکورانه و بدون وضعیت (Stateless) را غیرممکن می‌کند.
- مکانیزم: سیستم یک Payload را با منطق زیر تولید می‌کند:
$issued_at = time(); $nonce = wp_generate_password( 20, false, false ); $payload = 'v1.' . $issued_at . '.' . $nonce;. - امنیت: این Payload با استفاده از HMAC-SHA256 و نمک احراز هویت وردپرس امضا می‌شود:
$signature = hash_hmac( 'sha256', $payload, wp_salt( 'auth' ) );. - تحویل: اثبات نهایی در یک کوکی امن اول‌طرف (First-party) با ویژگی‌های
HttpOnly،SecureوSameSite=Laxذخیره می‌شود. - انقضا: اعتبار این اثبات تنها ۵ دقیقه است. پیش از آنکه ووکامرس عملیات
?add-to-cartرا پردازش کند، گارد امنیتی امضا و زمان انقضای اثبات را بررسی می‌کند.
غلبه بر کشینگ صفحات
کشینگ صفحات یک پیچیدگی عملی ایجاد کرد: صفحاتی که به شدت کش شده‌اند، بدون اجرای کد PHP مورد نیاز برای صدور کوکی اثبات، به کاربر ارائه می‌شوند. برای حل این موضوع بدون غیرفعال کردن کش کامل صفحه، Zologic یک نقطه اتصال (Endpoint) امن و سازگار با کش ایجاد کرد: /wp-json/wccg/v1/proof.
درخواستی به این Endpoint صراحتاً کشینگ را غیرفعال کرده و کوکی امضا شده را همراه با یک پاسخ JSON به صورت {"issued":true} برمی‌گرداند. این امر به فروشگاه اجازه می‌دهد تا وضعیت لازم را ایجاد کند و در عین حال عملکرد بالای سایت را از طریق کشینگ حفظ نماید.
مقیاس‌پذیری با Redis
برای رصد الگوهای تکاملی حمله، این لایه با Redis از طریق API کش-شیء (Object-cache) وردپرس ادغام شد. این روش نیاز به اتصال جداگانه به Redis را از بین می‌برد و اجازه می‌دهد سیستم سیگنال‌های سرعت (Velocity) را در لحظه رصد کند:
- تغییرات کلی سبد خرید در دقیقه: نظارت بر حجم کلی تغییرات وضعیت.
- نسبت اعتبارسنجی اثبات: رصد درخواست‌های دارای اثبات معتبر در مقابل درخواست‌های بدون اثبات.
- تغییرات رد شده: شمارش تعداد درخواست‌هایی که در لحظه مسدود می‌شوند.
- سرعت صدور اثبات: شناسایی ربات‌هایی که یاد گرفته‌اند برای برداشت کوکی‌ها به Endpoint
/proofدرخواست ارسال کنند.
این لایه مبتنی بر Redis تضمین می‌کند که اگر مهاجم با درخواست اول برای دریافت اثبات و سپس حمله به سبد خرید سازگار شود، سیستم همچنان بتواند سوءاستفاده را از طریق سیگنال‌های رفتاری و سرعت شناسایی کند. کنترل‌های امنیتی باید همگام با مهاجم تکامل یابند، نه اینکه تصور کنیم یک قانون برای همیشه کامل خواهد ماند.
حفظ تجارت عامل‌محور
Zologic در حال توسعه UCPReady است که پیاده‌سازی پروتکل جهانی تجارت (UCP) است. هدف این است که در حالی که حملات قدیمی مسدود می‌شوند، تجارت عامل‌محور (Agentic Commerce) — یعنی خریدهایی که توسط هوش مصنوعی برای انسان انجام می‌شود — فعال بماند. یک قانون مسدودسازی ساده، زیرساخت‌های آینده تجارتی را که آن‌ها را تعمداً باز گذاشته بودند، تخریب می‌کرد.
در این راستا، تفاوت‌های بنیادین در معماری پذیرش این عامل‌ها مشهود است؛ برای مثال بررسی رویکردهای متضاد آمازون و Shopify در پذیرش عامل‌های هوش مصنوعی نشان می‌دهد که هر پلتفرم چگونه سعی دارد تعادلی میان امنیت و دسترسی ایجاد کند.
آن‌ها دو مسیر اعتماد مجزا تعریف کردند تا ترافیک مرورگرهای قدیمی را از تجارت عامل‌محور تشخیص دهند:
۱. مسیر مرورگرهای قدیمی: مرورگر $\rightarrow$ اثبات اول‌طرف $\rightarrow$ افزودن قدیمی به سبد خرید $\rightarrow$ ووکامرس.
۲. مسیر تجارت عامل‌محور: عامل AI $\rightarrow$ مانیفست /.well-known/ucp $\rightarrow$ درگاه REST / MCP / Embedded checkout $\rightarrow$ ووکامرس.
این جداسازی باعث می‌شود عامل‌های AI نیازی به تقلید از مرورگر نداشته باشند. مانیفست UCP فروشگاه در آدرس /.well-known/ucp در دسترس است و از ترنسپورت‌های REST، MCP و Embedded پشتیبانی می‌کند. این معماری تشخیص می‌دهد که یک خزنده AI که متادیتای عمومی را دریافت می‌کند، با یک کلاینت ناشناس که سبد خرید را تغییر می‌دهد، متفاوت است.
اعتبارسنجی مستقل UCP
برای اطمینان از صحت عملکرد فراتر از تست‌های داخلی، Zologic از ابزار UCP Checker برای ارزیابی مستقل فروشگاه استفاده کرد. فروشگاه مورد نظر (House of Parfum) امتیاز کامل Grade A (100/100) را دریافت کرد، با نمرات کامل در بخش‌های:
- کشف عامل (Agent Discovery): ۱۰۰
- انطباق با UCP: ۱۰۰
- پوشش قابلیت‌ها: ۱۰۰
- ترنسپورت‌ها: REST, MCP, and Embedded
تست‌ها در UCP Playground به‌ویژه ارزشمند بود، زیرا مشکلات واقعی interoperability (میان‌کنش‌پذیری) را آشکار کرد که در محیط‌های توسعه کنترل‌شده نادیده گرفته شده بودند. این موضوع اهمیت مهندسی مبتنی بر استاندارد را برجسته می‌کند. تست پیاده‌سازی‌های مستقل برای بررسی مفروضات یکدیگر، برای موفقیت این پروتکل حیاتی است.
نتایج عملیاتی
پس از استقرار این تدابیر، نتایج قطعی بود. در یک نمونه آماری پس از اجرا، داده‌ها نشان داد:
- کل درخواست‌های افزودن به سبد خرید: ۳۶ مورد
- مسدود شده (خطای ۴۰۳): ۳۵ مورد
- پذیرفته شده (تغییر مسیر ۳۰۲): ۱ مورد
در مورد الگوی خاص بات‌های Chrome/150، تمام ۳۰ درخواست بدون استثنا با خطای ۴۰۳ رد شدند. آدرس‌های IP و User-Agentها همچنان در حال چرخش بودند، اما چون هویت IP دیگر خط دفاع اول نبود، دیگر نتوانستند از مرز امنیتی عبور کنند.
در همین حال، زیرساخت‌های قانونی UCP کاملاً عملیاتی باقی ماندند و برای موارد زیر پاسخ 200 OK بازگرداندند:
/.well-known/ucp/wp-json/ucpready/v1/openapi.json/wp-json/ucpready/v1/mcp-tools.json
درس آموخته شده
مهم‌ترین درس این حادثه، تغییر پرسش بنیادین بود. وقتی مهاجم می‌تواند هزاران آدرس را تغییر دهد، پرسش «آیا این IP ربات است؟» ارزش خود را از دست می‌دهد. پرسش درست این است: «آیا این کلاینت وضعیت و اعتبار لازم برای انجام این عملیات را ایجاد کرده است؟»
این اصل فراتر از ووکامرس است. با محافظت از عملیات و تعریف مرزهای اعتماد بر اساس پروتکل به جای هویت، Zologic بدون مختل کردن آینده تجارت ماشین-به-ماشین، جلوی سوءاستفاده‌ها را گرفت. برای کسانی که فروشگاه‌های پر ترافیک را مدیریت می‌کنند، راه حل یک لیست سیاه عظیم دیگر از IPها نیست، بلکه معماری امنیتی است که با عامل‌های قانونی به عنوان کلاینت‌های درجه یک برخورد کند و در عین حال برای تغییرات وضعیت گران‌قیمت، بافت (Context) سخت‌گیرانه‌ای را بخواهد.
مقابله با چالش‌های مشابه در ووکامرس
Zologic به توسعه این چارچوب‌ها ادامه می‌دهد تا به سایر فروشندگانی که با تهدیدات توزیع‌شده مشابه روبرو هستند کمک کند. هدف این است که از قوانین مسدودسازی گسترده‌ای که در نهایت عامل‌های قانونی را نیز در آتش می‌سوزانند، فاصله بگیریم.
اگر فروشگاه ووکامرس شما با موارد زیر دست و پنجه نرم می‌کند، یک رویکرد مبتنی بر وضعیت (State-based) ضروری است:
- سوءاستفاده توزیع‌شده از افزودن به سبد خرید: حجم بالای تغییرات بدون وضعیت در سبد خرید. این در حالی است که در شرایط عادی، بهینه‌سازی تعاملات سبد خرید توسط چت‌بات‌های هوش مصنوعی می‌تواند نرخ تبدیل را افزایش دهد، اما در اینجا هدف تخریب است.
- ترافیک پروکسی چرخان: مهاجمانی که از هزاران IP برای دور زدن محدودیت‌های نرخ (Rate Limits) استفاده می‌کنند.
- تخلیه منابع سبد خرید/نشست: فشار به منابع سرور ناشی از افزودن‌های خودکار به سبد خرید.
- تداخل خزنده AI: نیاز به اجازه دادن به عامل‌های AI قانونی در حالی که اسکرپرهای مخرب مسدود می‌شوند.
- یکپارچگی UCP/MCP: پیاده‌سازی پروتکل جهانی تجارت یا پروتکل بافت مدل برای تجارت عامل‌محور.
امن کردن ووکامرس بدون مسدود کردن عامل‌های AI قانونی نیازمند یک مدل دقیق است. راه حل باید با نحوه عملکرد واقعی فروشگاه شما سازگار باشد. اگر الگوهای ترافیکی مشابه را مشاهده می‌کنید، Zologic می‌تواند در بررسی و طراحی حفاظت مناسب یا یکپارچگی تجارت عامل‌محور به شما کمک کند.
گام بعدی شما
- اگر مدیر فروشگاه هستید، ترافیک سبد خرید خود را برای شناسایی درخواست‌های Stateless بررسی کنید.
- به جای گسترش لیست سیاه IPها، به دنبال پیاده‌سازی مکانیزم‌های Proof-of-State باشید.
- استانداردهای UCP و MCP را برای آماده‌سازی فروشگاه خود جهت پذیرش عامل‌های AI مطالعه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو