راهنمای جامع و پیشرفته دور زدن Rate Limiting در اسکن‌های امنیتی

مقدمه: جنگ نامرئی بین اسکنر و فایروال

در دنیای مدرن امنیت سایبری، مکانیزم‌های Rate Limiting تنها یک شمارنده ساده نیستند؛ آن‌ها الگوریتم‌های پیچیده‌ای هستند که رفتار کاربر را تحلیل می‌کنند. برای متخصصان تست نفوذ (Pentesters) و شکارچیان باگ (Bug Hunters)، برخورد با خطای 429 Too Many Requests یا بن شدن ناگهانی IP، می‌تواند پایان یک سناریوی تست باشد. اما در بسیاری از مواقع، این دیوارها نفوذپذیر هستند.

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

سلب مسئولیت قانونی: این مستند منحصراً برای اهداف آموزشی و ارتقای سطح دانش متخصصان امنیت جهت امن‌سازی زیرساخت‌ها تدوین شده است. هرگونه استفاده از این متدولوژی‌ها بر روی سرورها یا وب‌سایت‌هایی که مالکیت آن‌ها را ندارید یا مجوز کتبی تست نفوذ دریافت نکرده‌اید، جرم محسوب می‌شود.

استراتژی اول: فریب منطق شناسایی IP (IP Spoofing)

بسیاری از توسعه‌دهندگان وب برای استخراج IP کاربر از هدرهای استاندارد HTTP استفاده می‌کنند. مشکل زمانی رخ می‌دهد که سرور پشت یک Reverse Proxy یا CDN (مانند Cloudflare) باشد. در این معماری، اگر پیکربندی سرور وب (مانند Nginx یا Apache) صحیح نباشد، ممکن است به جای IP واقعی سوکت، به هدرهای قابل تزریق توسط کاربر اعتماد کند.

تکنیک عملیاتی:

شما می‌توانید با ارسال هدرهایی که ادعا می‌کنند IP اصلی چیز دیگری است (مثلاً لوکال‌هاست یا یک IP داخلی معتبر)، سیستم Rate Limit را گیج کنید. لیست توسعه‌یافته زیر را در هر درخواست تست کنید:

X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Host: 127.0.0.1
X-Forwarded-Host: 127.0.0.1
X-Real-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
Client-IP: 127.0.0.1

تحلیل فنی: اگر برنامه به هدر X-Forwarded-For اعتماد کند و مقدار آن را پردازش نماید، با تغییر این مقدار در هر درخواست (مثلاً 1.1.1.1، 1.1.1.2 و…)، سرور تصور می‌کند که با هزاران کاربر مختلف روبرو است، نه یک مهاجم واحد.

استراتژی دوم: دور زدن محدودیت‌های مبتنی بر نشست (Session-Based Limits)

همیشه IP ملاک محدودیت نیست. بسیاری از فایروال‌های مدرن، محدودیت نرخ را بر اساس کوکی نشست (Session Cookie) یا توکن احراز هویت (API Key/JWT) اعمال می‌کنند. در این سناریو، حتی اگر IP خود را تغییر دهید، تا زمانی که با همان حساب کاربری لاگین هستید، محدود خواهید شد.

راهکارها:

• حذف کوکی‌ها: اگر در حال اسکن صفحات عمومی (Public) هستید، هدر Cookie را به طور کامل از درخواست‌های خود حذف کنید. گاهی Rate Limit فقط روی کاربران لاگین شده اعمال می‌شود.
• چرخش نشست‌ها (Session Rotation): اگر نیاز به احراز هویت دارید، ۱۰ یا ۲۰ حساب کاربری بسازید و اسکنر خود را تنظیم کنید تا پس از هر ۲۰ درخواست، از توکن حساب بعدی استفاده کند.
• بررسی پارامترهای ردیابی: گاهی سرور یک کوکی خاص (مثلاً cf_uid یا tracking_id) ست می‌کند. شناسایی و حذف یا تغییر مداوم این کوکی‌ها حیاتی است.

استراتژی سوم: دستکاری ساختار URL و پارامترها (Path Obfuscation)

قوانین WAF اغلب بر اساس عبارات منظم (Regex) نوشته می‌شوند. اگر ادمین سرور قانونی نوشته باشد که دقیقاً /login را محدود کند، هر تغییری که از دید وب‌سرور نهایی یکسان تفسیر شود اما از دید WAF متفاوت باشد، می‌تواند مکانیزم دفاعی را دور بزند.

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

• /site/login (استاندارد)
• /site/./login (استفاده از نقطه برای دایرکتوری جاری)
• /site/foo/../login (پیمایش دایرکتوری معکوس)
• /site//login (اسلش‌های تکراری که توسط اکثر وب‌سرورها نرمال‌سازی می‌شوند)
• /site/login.php (اضافه کردن پسوند فایل در فریم‌ورک‌های MVC)
• /site/login?random=123 (اضافه کردن پارامترهای بی‌اثر برای تغییر هش درخواست)
• /site/login%09 (استفاده از تب یا کاراکترهای وایت‌اسپیس انکود شده)

استراتژی چهارم: تغییر متدولوژی درخواست و هدرها

گاهی محدودیت فقط روی متد POST (که سنگین‌تر است) اعمال می‌شود. وب‌سرورها گاهی طوری کانفیگ شده‌اند که اگر متد HEAD ارسال کنید، پردازش سمت سرور انجام می‌شود اما بدنه‌ای بازگردانده نمی‌شود، که برای Brute Force کافی است.

تکنیک Override: بسیاری از فریم‌ورک‌ها (مانند Laravel یا Rails) از هدرهای خاصی برای تغییر متد در لایه اپلیکیشن پشتیبانی می‌کنند، حتی اگر درخواست اصلی GET باشد.

X-HTTP-Method-Override: POST
X-HTTP-Method: POST
X-Method-Override: POST

استراتژی پنجم: تکنیک انسانی‌سازی (Humanization & Jitter)

الگوریتم‌های پیشرفته تشخیص بات، به زمان‌بندی درخواست‌ها حساس هستند. اگر شما دقیقاً هر ۵۰۰ میلی‌ثانیه یک درخواست بفرستید، یک الگوی ماشینی ایجاد کرده‌اید که به سرعت شناسایی می‌شود.

تکنیک Jitter (تاخیر تصادفی):

در ابزارهای اسکن خود حتماً گزینه “Delay” را روی یک عدد ثابت نگذارید. از “Random Delay” استفاده کنید. برای مثال، بین ۰.۵ تا ۲ ثانیه تاخیر متغیر ایجاد کنید. این کار الگوی زمانی را به هم می‌ریزد و شبیه‌تر به رفتار انسانی (که نامنظم کلیک می‌کند) می‌شود.

استراتژی ششم: شرایط رقابتی (Race Condition)

این یکی از قدرتمندترین تکنیک‌ها برای دور زدن محدودیت‌های منطقی (Logical Rate Limits) است، مثلاً زمانی که سایت اجازه “فقط یک بار استفاده از کد تخفیف” یا “۵ تلاش لاگین در دقیقه” را می‌دهد. فاصله زمانی بسیار کوتاهی بین “چک کردن تعداد درخواست‌ها در دیتابیس” و “افزایش شمارنده درخواست‌ها” وجود دارد (Time-of-check to time-of-use). اگر بتوانید تمام درخواست‌های خود را دقیقاً در همین پنجره زمانی (میلی‌ثانیه) ارسال کنید، همگی قبل از آپدیت شدن شمارنده پردازش می‌شوند.

ابزار Turbo Intruder در Burp Suite دقیقاً برای همین کار ساخته شده است؛ ارسال موازی آخرین بایت درخواست‌ها برای همگام‌سازی دقیق زمان رسیدن به سرور.

ابزارهای دفاعی و راهکارهای امن‌سازی

برای مدیران سرور، مقابله با این تکنیک‌ها نیازمند پیکربندی چندلایه است:

• پیکربندی صحیح Trust Proxy: در وب‌سرور خود تعیین کنید که هدر X-Forwarded-For فقط و فقط از سمت IPهای شناخته شده (مثل رنج IP کلودفلر) پذیرفته شود.
• Device Fingerprinting: به جای تکیه بر IP یا کوکی که قابل حذف است، از کتابخانه‌هایی استفاده کنید که مشخصات سخت‌افزاری و نرم‌افزاری مرورگر کاربر (Canvas hash, AudioContext, Fonts) را ترکیب کرده و یک شناسه منحصر به فرد (Fingerprint) تولید می‌کنند.
• Honey Pots (تله‌گذاری): لینک‌های مخفی در کد HTML قرار دهید که با CSS از دید کاربر مخفی شده‌اند (display: none). اگر درخواستی به این لینک‌ها آمد، قطعاً از سمت یک اسکنر خودکار است و باید بلافاصله بن شود.

جمع‌بندی نهایی

موفقیت در دور زدن Rate Limit به خلاقیت شما بستگی دارد. هیچ تنظیم پیش‌فرضی در اسکنرها وجود ندارد که همه جا کار کند. شما باید پاسخ‌های سرور را تحلیل کنید؛ آیا کد ۴۲۹ دریافت می‌کنید یا ۴۰۳؟ آیا بعد از تعداد مشخصی درخواست بن می‌شوید یا بر اساس سرعت؟ پاسخ به این سوالات، استراتژی دور زدن را مشخص می‌کند.