🔍 تحلیل یک باگ جالب در Node.js و llhttp
در این آسیب‌پذیری، مهاجم هدر زیر را همراه با یک درخواست جعلی ارسال می‌کند:

Connection: close<TAB>

منظور از <TAB> یک کاراکتر تب واقعی بعد از کلمه close است.
معماری معمول هدف:

Attacker → Reverse Proxy → Node.js Backend

فرانت‌اند یا Reverse Proxy ممکن است مقدار زیر را همان Connection: close در نظر بگیرد:

Connection: close<TAB>

یعنی تصور کند بعد از پردازش درخواست فعلی، اتصال باید بسته شود.
اما در نسخه آسیب‌پذیر llhttp، وجود تب باعث می‌شد پرچم داخلی CONNECTION_CLOSE به‌درستی فعال نشود.
در نتیجه Node.js تصور می‌کرد اتصال همچنان قابل استفاده است و بایت‌های اضافی تحت کنترل مهاجم را به‌عنوان یک درخواست HTTP جدید پردازش می‌کرد.

برداشت Reverse Proxy:

[ درخواست اول ]
[ پایان اتصال ]


برداشت Node.js:

[ درخواست اول ]
[ درخواست جعلی دوم ]

نکته مهم این است که بک‌اند «درخواست را باز نگه نمی‌دارد»؛ بلکه اتصال بین Reverse Proxy و Backend را باز و قابل‌استفاده نگه می‌دارد.
همین اختلاف تفسیر باعث ایجاد HTTP Desynchronization و در شرایط مناسب HTTP Request Smuggling می‌شود.
✅ ریشه اصلی باگ در llhttp و سمت Node.js است، نه الزاماً Reverse Proxy.
اما بهره‌برداری واقعی به رفتار Reverse Proxy هم وابسته است؛ برای مثال:
• هدر را به بک‌اند منتقل کند
• اتصال بک‌اند را دوباره استفاده کند
• مقدار close<TAB> را متفاوت از Node.js تفسیر کند
اگر Reverse Proxy هدر Connection را حذف یا به‌درستی بازسازی کند، ممکن است باگ Node.js قابل بهره‌برداری نباشد.
خلاصه:

Connection: close<TAB>
        ↓
Reverse Proxy آن را close می‌فهمد
        ↓
Node.js آن را close تشخیص نمی‌دهد
        ↓
اتصال Backend باز می‌ماند
        ↓
بایت‌های اضافی درخواست جدید محسوب می‌شوند

گزارش اصلی:
https://hackerone.com/reports/3723248
#NodeJS #CyberSecurity #RequestSmuggling #HTTP #BugBounty