HTTP Request Smuggling چیست؟ بررسی حمله قاچاق درخواست HTTP

HTTP Request Smuggling یا «قاچاق درخواست HTTP» یک آسیب‌پذیری امنیتی است که زمانی رخ می‌دهد که دو یا چند جزء در مسیر پردازش درخواست‌های HTTP، مرز شروع و پایان یک Request را به شکل متفاوتی تفسیر کنند. برای مثال ممکن است Reverse Proxy تصور کند یک درخواست در نقطه‌ای تمام شده، اما Back-end Server بخشی از همان داده را آغاز یک درخواست جدید بداند. این اختلاف می‌تواند باعث Desynchronization یا ناهماهنگی در زنجیره HTTP شود و در شرایط آسیب‌پذیر امکان عبور از بعضی کنترل‌های امنیتی، آلوده‌سازی Cache یا مخلوط شدن درخواست‌های کاربران را ایجاد کند.

این ضعف در CWE با شناسه CWE-444 و عنوان Inconsistent Interpretation of HTTP Requests شناخته می‌شود. MITRE توضیح می‌دهد مشکل زمانی شکل می‌گیرد که Proxy، Firewall، Load Balancer یا سایر واسطه‌های HTTP یک پیام غیرعادی را متفاوت از مقصد نهایی تفسیر کنند.

در حملات کلاسیک HTTP/1.1، اختلاف معمولاً بر سر نحوه تعیین طول Body است. دو مکانیزم مهم Content-Length و Transfer-Encoding می‌توانند در Configurationها یا Parserهای ناسازگار باعث ابهام شوند. RFC 9112 صراحتاً می‌گوید Sender نباید در پیامی که Transfer-Encoding دارد Content-Length نیز ارسال کند و دریافت چنین ترکیبی می‌تواند نشانه Request Smuggling باشد.

اما Request Smuggling فقط یک مشکل قدیمی HTTP/1.1 نیست. معماری‌های مدرن دارای CDN، WAF، Reverse Proxy، Load Balancer، API Gateway و تبدیل HTTP/2 به HTTP/1.1 نیز می‌توانند زمینه اختلاف Parsing را ایجاد کنند. OWASP در Web Security Testing Guide جدید خود نیز HTTP/2 Downgrade و تفاوت در Normalization بین اجزای Front-end و Back-end را بخشی از Attack Surface مدرن Request Smuggling معرفی می‌کند.

در این مقاله رخنه‌کاو بررسی می‌کنیم HTTP Request Smuggling چیست، چرا اختلاف تفسیر Headerها خطرناک است، CL.TE و TE.CL چه مفهومی دارند، HTTP/2 Downgrade چه نقشی دارد، چه پیامدهایی ممکن است ایجاد شود و مهم‌تر از همه چگونه می‌توان معماری وب را در برابر این خانواده آسیب‌پذیری‌ها امن کرد.

HTTP Request Smuggling چیست؟

برای درک HTTP Request Smuggling باید بدانیم بسیاری از سایت‌های امروزی Request کاربر را مستقیماً به Application Server نمی‌رسانند.

یک درخواست ممکن است این مسیر را طی کند:

Browser

→ CDN

→ WAF

→ Load Balancer

→ Reverse Proxy

→ Web Server

→ Application Server

گاهی چند Component دیگر نیز بین این مراحل قرار دارند.

هر Component باید تشخیص دهد:

Request از کجا شروع می‌شود؟

Headerها کجا تمام می‌شوند؟

Body چند Byte است؟

Request بعدی از کجا آغاز می‌شود؟

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

اما اگر Front-end و Back-end درباره مرز Message اختلاف داشته باشند، بخشی از داده‌ای که Component اول آن را Body Request قبلی می‌بیند ممکن است توسط Component دوم به‌عنوان Request جدید تفسیر شود.

OWASP این آسیب‌پذیری را نتیجه ناسازگاری در Parsing درخواست HTTP میان Front-end و Back-end می‌داند.

چرا نام آن Request Smuggling است؟

Smuggling به معنی «قاچاق» است.

در اینجا منظور این است که داده‌ای که از دید یکی از واسطه‌های HTTP بخشی از یک Request عادی است، از دید سرور دیگری تبدیل به یک Request جداگانه می‌شود.

در نتیجه Request دوم ممکن است بدون اینکه Front-end آن را به شکل مستقل دیده و کنترل کرده باشد به Back-end برسد.

از همین رو اصطلاح:

HTTP Request Smuggling

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

CWE-444 چیست؟

CWE-444 عنوان رسمی:

Inconsistent Interpretation of HTTP Requests

را دارد.

این CWE مخصوص شرایطی است که یک واسطه HTTP مانند:

Proxy

Firewall

Load Balancer

Cache

یا Gateway

Request را متفاوت از Endpoint نهایی تفسیر می‌کند.

MITRE پیامدهای این ضعف را شامل مواردی مانند:

Bypass Protection Mechanism

Unexpected State

Cache Poisoning

و Access Control Problems

معرفی می‌کند.

نکته مهم این است که CWE-444 به یک زبان برنامه‌نویسی خاص وابسته نیست.

ممکن است:

PHP

Java

.NET

Node.js

Python

Go

یا هر Backend دیگری

پشت معماری آسیب‌پذیر قرار داشته باشد.

ریشه اصلی معمولاً Interaction میان چند HTTP Parser است.

برای فهم Request Smuggling ابتدا باید HTTP Message Framing را بشناسیم

HTTP Server باید بداند Body یک Request دقیقاً چه اندازه‌ای دارد.

فرض کنید Connection میان Proxy و Web Server برای چند Request پشت سر هم استفاده می‌شود.

Server باید بتواند این Sequence را تشخیص دهد:

Request 1

Body Request 1

Request 2

Body Request 2

Request 3

اگر Server مرز Request اول را اشتباه تشخیص دهد، تمام Requestهای بعدی ممکن است جابه‌جا شوند.

به این مشکل Desynchronization یا به اختصار Desync گفته می‌شود.

Content-Length چیست؟

Header زیر طول Body را به Byte مشخص می‌کند:

Content-Length

مثلاً اگر Application اعلام کند Body دارای 100 Byte است، Receiver انتظار دارد دقیقاً همان مقدار Data را به Body Request اختصاص دهد.

پس از آن Request بعدی می‌تواند آغاز شود.

Transfer-Encoding چیست؟

HTTP/1.1 مکانیزم دیگری نیز برای انتقال Body دارد:

Transfer-Encoding

شناخته‌شده‌ترین شکل آن Chunked Transfer Coding است.

در این حالت Body به Chunkهای مختلف تقسیم می‌شود و Protocol ساختار پایان Body را مشخص می‌کند.

RFC 9112 بیان می‌کند Transfer-Encoding در HTTP برای Message Delimiting نیز کاربرد دارد.

چرا Content-Length و Transfer-Encoding می‌توانند مشکل ایجاد کنند؟

مشکل اصلی زمانی شکل می‌گیرد که بیش از یک Parser در مسیر Request وجود داشته باشد و آن‌ها درباره Headerهای تعیین‌کننده طول پیام رفتار متفاوتی داشته باشند.

برای مثال:

Front-end یک Header را معتبر بداند.

Back-end همان Header را نادیده بگیرد.

یا برعکس.

RFC 9112 تلاش می‌کند این ابهام را حذف کند.

طبق استاندارد، Sender نباید Request دارای Transfer-Encoding را همراه Content-Length ارسال کند.

اگر یک Message هر دو را داشته باشد، Transfer-Encoding از نظر قواعد Message Framing اولویت دارد و چنین Messageای باید مشکوک تلقی شود. استاندارد همچنین برای جلوگیری از سوءاستفاده، بستن Connection را پس از پردازش چنین Requestهایی مطرح می‌کند.

اما Vulnerability زمانی ایجاد می‌شود که تمام اجزای Infrastructure این قواعد را یکسان اجرا نکنند.

HTTP Request Desynchronization چیست؟

Request Smuggling اغلب زیر عنوان HTTP Desync نیز بررسی می‌شود.

Desync یعنی دو Component درباره Position فعلی Stream توافق ندارند.

Front-end ممکن است تصور کند:

Request اول تمام شد.

اما Back-end هنوز بخشی از Data را متعلق به همان Request بداند.

یا بالعکس.

در نتیجه Byteهای باقی‌مانده ممکن است با Request کاربر بعدی ترکیب شوند.

این موضوع علت اصلی خطرناک بودن Request Smuggling است.

مشکل فقط Request مهاجم نیست؛ ممکن است Queue Requestهای کاربران دیگر نیز تحت تأثیر قرار گیرد.

معماری Front-end و Back-end چگونه باعث Request Smuggling می‌شود؟

تصور کنید معماری زیر وجود دارد:

User → Reverse Proxy → Application Server

Reverse Proxy مسئول:

TLS Termination

Rate Limiting

WAF

Routing

Caching

است.

Application Server نیز Request پردازش‌شده را دریافت می‌کند.

اگر Proxy و Application Server یک HTTP Message را متفاوت Parse کنند، مرز امنیتی ایجاد می‌شود.

مثلاً Proxy ممکن است Request را Safe تشخیص دهد و Forward کند.

اما Back-end Interpretation متفاوتی داشته باشد و Data پنهان‌شده در انتهای Request را به عنوان یک Request جدید پردازش کند.

به همین دلیل HTTP Request Smuggling بیشتر از اینکه فقط «Bug در Application Code» باشد، یک مشکل معماری و Protocol Parsing است.

CL.TE چیست؟

CL مخفف:

Content-Length

و TE مخفف:

Transfer-Encoding

است.

CL.TE به حالتی گفته می‌شود که:

Front-end طول Request را براساس Content-Length تعیین می‌کند.

اما Back-end آن را براساس Transfer-Encoding تفسیر می‌کند.

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

PortSwigger این مدل را یکی از Classificationهای کلاسیک HTTP Request Smuggling معرفی می‌کند.

مهم است بدانیم CL.TE یک Payload مشخص نیست؛ بلکه توصیف نوع اختلاف Parsing است.

TE.CL چیست؟

در TE.CL ترتیب برعکس است.

Front-end:

Transfer-Encoding

را مبنای Message Framing می‌گیرد.

Back-end:

Content-Length

را مبنا قرار می‌دهد.

در نتیجه همان Request می‌تواند دو طول متفاوت از دید دو Component داشته باشد.

اختلاف در Message Boundary زمینه Desynchronization را ایجاد می‌کند.

TE.TE چیست؟

TE.TE نوعی شرایط ناسازگارتر است که هر دو Server ظاهراً Transfer-Encoding را پشتیبانی می‌کنند اما یکی از آن‌ها به دلیل اختلاف Parsing یا Syntax Variation رفتار دیگری نشان می‌دهد.

در سیستم‌های به‌روز و Strict Parsing احتمال بسیاری از Variantهای قدیمی کمتر شده است.

با این حال اصل آسیب‌پذیری همچنان پابرجاست:

دو Parser یک Request واحد را نباید متفاوت تفسیر کنند.

آیا Duplicate Content-Length خطرناک است؟

وجود چند Content-Length متفاوت نیز می‌تواند Ambiguity ایجاد کند.

برای مثال اگر دو Header مختلف طول Body متفاوتی را اعلام کنند، رفتار Componentها ممکن است یکسان نباشد.

یک Server ممکن است:

اولی را قبول کند.

یکی دیگر آخری را.

یا Request را Reject کند.

راهکار امن این است که Requestهای Ambiguous اصلاً Forward نشوند.

MITRE نیز اختلاف در تفسیر Duplicate Headerهایی مانند Content-Length و Transfer-Encoding را از Scenarioهای CWE-444 معرفی می‌کند.

RFC 9112 درباره Request Smuggling چه می‌گوید؟

RFC 9112 استاندارد اصلی HTTP/1.1 Message Syntax و Routing است.

این RFC Request Smuggling را صراحتاً در Section 11.2 توضیح می‌دهد و آن را Techniqueای می‌داند که از اختلاف Protocol Parsing میان Recipients استفاده می‌کند تا Request اضافی در یک Request ظاهراً بی‌خطر پنهان شود.

چند Rule امنیتی بسیار مهم در RFC وجود دارد:

Sender نباید همزمان Transfer-Encoding و Content-Length ارسال کند.

اگر هر دو موجود باشند، Request ممکن است نشانه تلاش برای Smuggling باشد.

Intermediary که Message را Forward می‌کند باید Ambiguity را از بین ببرد.

برای Messageهای غیرقابل اعتماد Connection باید در شرایط مشخص بسته شود.

این موارد نشان می‌دهد Strict HTTP Compliance یک بخش مهم Prevention است.

HTTP/2 چه تفاوتی ایجاد می‌کند؟

HTTP/2 ساختار Message متفاوتی نسبت به HTTP/1.1 دارد.

در HTTP/2 داده در Frame منتقل می‌شود و Frameها Length مشخص دارند.

به همین دلیل اگر HTTP/2 واقعاً End-to-End استفاده شود، Ambiguity کلاسیک Content-Length و Transfer-Encoding تا حد زیادی از مدل Protocol حذف می‌شود.

PortSwigger توضیح می‌دهد HTTP/2 End-to-End یک Mechanism مشخص و Robust برای تعیین طول Message دارد و Request Smuggling کلاسیک HTTP/1 را ندارد.

اما یک مشکل بسیار مهم وجود دارد:

HTTP/2 Downgrading.

HTTP/2 Downgrade چیست؟

در بسیاری از معماری‌ها:

Client → HTTP/2 → Front-end

اما:

Front-end → HTTP/1.1 → Back-end

است.

Front-end مجبور می‌شود Request HTTP/2 را به HTTP/1.1 تبدیل کند.

این Conversion یا Downgrade می‌تواند دوباره Message Framing Headerهایی مانند Content-Length یا Transfer-Encoding را وارد زنجیره کند.

اگر Conversion به‌درستی Validate نشود، اختلاف Parser ممکن است دوباره ایجاد شود.

PortSwigger HTTP/2 Downgrading را یکی از مهم‌ترین Attack Surfaceهای Request Smuggling مدرن معرفی می‌کند.

H2.CL چیست؟

H2.CL نوعی Desync مرتبط با HTTP/2 Downgrade است.

Front-end Request را براساس Frameهای HTTP/2 دریافت می‌کند.

اما بعد از تبدیل Request به HTTP/1، Back-end ممکن است Content-Length ایجادشده یا منتقل‌شده را مبنای Body Length قرار دهد.

اگر Lengthهای این دو Representation با یکدیگر سازگار نباشند، Desync ممکن است رخ دهد.

این موضوع نشان می‌دهد فقط Upgrade کردن Edge Server به HTTP/2 لزوماً Request Smuggling را حل نمی‌کند.

مهم است Protocol در تمام مسیر چگونه مدیریت می‌شود.

H2.TE چیست؟

در H2.TE نیز Translation میان HTTP/2 و HTTP/1 می‌تواند باعث شود Transfer-Encoding در Representation Back-end نقش داشته باشد.

اگر Front-end و Back-end مرز Message را یکسان درک نکنند، Request Smuggling ممکن می‌شود.

بنابراین بهترین حالت زمانی است که Protocol Translation غیرضروری حذف شود یا Gateway با Validation سخت‌گیرانه انجام شود.

آیا HTTP/2 به‌تنهایی مشکل را حل می‌کند؟

نه اگر فقط در سمت Client فعال باشد.

اگر مسیر این باشد:

Browser → HTTP/2 → CDN

CDN → HTTP/1.1 → Load Balancer

Load Balancer → HTTP/1.1 → Web Server

هنوز بخش بزرگی از مسیر از Parserهای HTTP/1 استفاده می‌کند.

به همین دلیل PortSwigger توصیه می‌کند در صورت امکان HTTP/2 به شکل End-to-End استفاده شود و HTTP Downgrading حذف شود.

CL.0 چیست؟

در تحقیقات جدیدتر HTTP Desync نوع دیگری از مشکل نیز بررسی شده است که معمولاً با عنوان CL.0 شناخته می‌شود.

در این Scenario یک Component برای Request Body به Content-Length توجه می‌کند اما Component دیگر ممکن است برای Route یا شرایط خاص Body را نادیده بگیرد.

نتیجه باز هم یکی است:

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

PortSwigger تحقیقات Browser-Powered Desync را بر پایه همین خانواده اختلاف‌ها توسعه داده است.

برای دفاع، Application و Web Server نباید صرفاً فرض کنند بعضی Methodها یا Endpointها هیچ‌گاه Body ندارند.

چرا Request Smuggling خطرناک است؟

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

یک Desync کوچک ممکن است فقط Connection Error ایجاد کند.

اما در Environment دیگر ممکن است:

WAF Bypass

Access Control Bypass

Cache Poisoning

Request Queue Poisoning

Credential Exposure

Session Exposure

و Attack علیه کاربران دیگر

ایجاد کند.

MITRE و OWASP هر دو Bypass کنترل‌های امنیتی و Cache-related Impact را در این خانواده ضعف‌ها مطرح می‌کنند.

عبور از Front-end Security Controls

یکی از مهم‌ترین سناریوها این است که Security Control فقط روی Front-end قرار دارد.

مثلاً Reverse Proxy دسترسی به:

/admin

را Block می‌کند.

اما Back-end چنین محدودیتی ندارد، چون تیم توسعه تصور کرده همه Traffic حتماً از Front-end عبور می‌کند.

اگر یک Request دوم بدون Interpretation صحیح Front-end به Back-end برسد، ممکن است Security Control دور زده شود.

این موضوع نشان می‌دهد Defense in Depth اهمیت دارد.

Back-end نیز باید Authorization واقعی داشته باشد.

هیچ Route حساسی نباید صرفاً به این دلیل امن تلقی شود که WAF یا Reverse Proxy آن را Filter می‌کند.

Request Queue Poisoning چیست؟

Backend Connectionها اغلب برای Performance Reuse می‌شوند.

یعنی Proxy برای هر User Connection جدید به Back-end ایجاد نمی‌کند.

یک Connection می‌تواند مجموعه‌ای از Requestهای کاربران مختلف را پشت سر هم منتقل کند.

اگر Desync رخ دهد، Data باقی‌مانده از Request یک User ممکن است روی Request بعدی اثر بگذارد.

به همین دلیل به این دسته رفتارها Request Queue Poisoning نیز گفته می‌شود.

خطر اصلی این است که Impact ممکن است به Request مهاجم محدود نماند.

Web Cache Poisoning چیست؟

Cacheها Response یک URL را برای Requestهای بعدی ذخیره می‌کنند.

اگر Request Smuggling باعث شود Cache و Back-end Requestها را متفاوت Associate کنند، ممکن است Content مربوط به یک Request تحت Cache Key دیگری ذخیره شود.

CWE-444 نیز Cache Poisoning را از Consequenceهای شناخته‌شده این ضعف می‌داند.

در صورت Cacheable بودن Response، Impact ممکن است برای تعداد زیادی User تکرار شود.

افشای اطلاعات کاربران

در بعضی Desync Scenarioها Request بعدی User می‌تواند با Data باقی‌مانده از Request مهاجم ترکیب شود.

در Architecture خاص این مسئله می‌تواند منجر به:

Exposure Header

Token

Cookie

Request Body

یا اطلاعات دیگر

شود.

اما چنین Impactی به Configuration دقیق Server، Logging، Endpoint و Queue Behavior وابسته است.

نباید فرض کرد هر Request Smuggling خودکار به سرقت Credential منجر می‌شود.

آیا Request Smuggling می‌تواند WAF را دور بزند؟

بله، در بعضی معماری‌ها.

اگر WAF Request را یک شکل تفسیر کند ولی Backend شکل دیگری، WAF ممکن است Payload یا Request دوم را به شکل مستقل بررسی نکرده باشد.

اما دفاع صحیح این نیست که فقط Signatureهای WAF را بیشتر کنیم.

Root Cause باید رفع شود:

تمام HTTP Parserها باید Request Boundary یکسان داشته باشند.

HTTP Request Smuggling و HTTP Response Smuggling چه تفاوتی دارند؟

Request Smuggling روی Interpretation درخواست‌ها تمرکز دارد.

Response Smuggling روی اختلاف Interpretation پاسخ‌ها.

هر دو در CWE-444 کنار یکدیگر قرار گرفته‌اند و Root Cause مشابهی دارند:

Inconsistent HTTP Parsing.

در Request Smuggling:

Client → Server

مسیر اصلی مسئله است.

در Response Smuggling:

Server → Client

یا Intermediary Response Parsing

محور اصلی است.

تفاوت HTTP Request Smuggling با HTTP Request Splitting

Request Splitting معمولاً به تزریق داده‌ای اشاره می‌کند که باعث ایجاد چند Request از یک Input شود.

Request Smuggling بیشتر به اختلاف Parserها و Message Boundary میان Componentها وابسته است.

این دو ممکن است در بعضی Scenarioها همپوشانی داشته باشند، اما Root Cause یکسان نیست.

تفاوت Request Smuggling با CRLF Injection

CRLF Injection از کاراکترهای Line Break برای تغییر Header یا Message Structure سوءاستفاده می‌کند.

Request Smuggling می‌تواند در بعضی Variantها از Header Parsing غیرعادی تأثیر بگیرد، اما مفهوم گسترده‌تری است.

ممکن است هیچ CRLF Injection در Application وجود نداشته باشد ولی Proxy و Backend همچنان Request را متفاوت Parse کنند.

تفاوت Request Smuggling با SSRF

در SSRF، Server وادار می‌شود Requestی به Destination دیگری ارسال کند.

در Request Smuggling، مهاجم تلاش می‌کند Request Boundary میان اجزای HTTP را Desync کند.

هر دو ممکن است در نهایت دسترسی به Internal Functionality ایجاد کنند، اما Mechanism کاملاً متفاوت است.

چه معماری‌هایی بیشتر باید بررسی شوند؟

وجود چند HTTP Processing Layer Attack Surface را افزایش می‌دهد.

به‌خصوص Architectureهای دارای:

CDN

Reverse Proxy

Load Balancer

WAF

API Gateway

Caching Proxy

Ingress Controller

Service Mesh Gateway

Legacy Web Server

HTTP/2-to-HTTP/1 Translation

باید Message Parsing Consistency را جدی‌تر بررسی کنند.

وجود این Componentها به معنی Vulnerability نیست.

اما هر Translation Boundary محل مناسبی برای Security Review است.

Request Smuggling در معماری CDN

در یک معماری معمول:

Browser

→ CDN

→ Origin Server

CDN ممکن است:

HTTP/2 یا HTTP/3 را از Client دریافت کند.

Request را Normalize کند.

آن را با HTTP/1.1 به Origin ارسال کند.

اگر Origin Parser رفتار متفاوتی داشته باشد، Downgrade Boundary می‌تواند Attack Surface ایجاد کند.

CDN به‌تنهایی تضمین نمی‌کند Origin در برابر Smuggling امن است.

Request Smuggling و Reverse Proxy

Reverse Proxy یکی از رایج‌ترین Componentهای درگیر است.

مثلاً:

Nginx

Apache

HAProxy

Envoy

IIS ARR

و محصولات مشابه.

مشکل معمولاً زمانی ایجاد می‌شود که Version، Configuration یا Parsing Behavior دو Component متفاوت باشد.

هدف Security Team باید ایجاد یک Contract واضح برای Request Normalization باشد.

Request Smuggling و Load Balancer

Load Balancer نیز Request را Parse می‌کند.

اگر Headerهای Ambiguous را بدون Reject کردن Forward کند، Backend مجبور می‌شود دوباره آن‌ها را Parse کند.

هر بار Parse مجدد فرصتی برای Interpretation متفاوت ایجاد می‌کند.

یک Load Balancer امن باید Requestهای ناسازگار با HTTP Specification را Normalize یا Reject کند.

Request Smuggling در API Gateway

API Gateway ممکن است:

Authentication

Rate Limiting

Schema Validation

Routing

را انجام دهد.

اگر Back-end Request دیگری ببیند که Gateway آن را ندیده، تمام این Controls ممکن است بی‌اثر شوند.

به همین دلیل Gateway نباید تنها Security Boundary Application باشد.

Backend Authorization همچنان ضروری است.

HTTP Request Smuggling در WordPress

HTTP Request Smuggling معمولاً یک آسیب‌پذیری مستقیم در WordPress Core یا PHP Theme نیست.

این موضوع بیشتر در HTTP Infrastructure اطراف WordPress شکل می‌گیرد.

یک سایت WordPress ممکن است معماری زیر را داشته باشد:

Cloud CDN

→ WAF

→ Nginx

→ Apache

→ PHP-FPM

→ WordPress

هر Layer می‌تواند بخشی از Request Processing باشد.

اگر CDN، Reverse Proxy و Origin Server درباره Request Boundary اختلاف داشته باشند، خود WordPress ممکن است Requestی دریافت کند که Front-end به شکل دیگری تفسیر کرده است.

بنابراین در سایت WordPress سؤال اصلی این نیست:

«آیا افزونه ضد Request Smuggling نصب کرده‌ایم؟»

سؤال صحیح این است:

«زنجیره HTTP قبل از رسیدن Request به WordPress چگونه Requestها را Parse و Normalize می‌کند؟»

آیا افزونه امنیتی وردپرس می‌تواند Request Smuggling را حل کند؟

معمولاً نه به‌تنهایی.

اگر Desynchronization بین Reverse Proxy و Web Server قبل از اجرای PHP رخ دهد، Plugin WordPress ممکن است اصلاً Request اولی که باعث مشکل شده را به شکل کامل نبیند.

Plugin Security همچنان برای Application Security مفید است، اما Fix اصلی Request Smuggling معمولاً در:

Web Server

Reverse Proxy

CDN

Load Balancer

یا API Gateway

انجام می‌شود.

Request Smuggling در WooCommerce

WooCommerce به دلیل وجود:

Login

Checkout

Cart

Payment Callback

REST API

Admin

و Session

می‌تواند Impact بالقوه بالاتری در صورت وجود زیرساخت آسیب‌پذیر داشته باشد.

اما خود فروشگاه تنها به دلیل WooCommerce بودن Vulnerable نیست.

مشکل همچنان در Request Processing Chain است.

وجود Endpointهای حساس فقط Impact احتمالی را بیشتر می‌کند.

چرا Backend Authorization اهمیت دارد؟

فرض کنید Reverse Proxy دسترسی به Admin Route را Block می‌کند.

اگر Backend خودش Permission Check نداشته باشد، Security Architecture به Front-end وابسته شده است.

Secure Design می‌گوید عملیات حساس باید در Application نیز Authorize شوند.

حتی اگر Request Smuggling وجود نداشته باشد، Defense in Depth چنین طراحی‌ای را ایمن‌تر می‌کند.

روش‌های جلوگیری از HTTP Request Smuggling

مؤثرترین روش‌ها روی حذف Ambiguity متمرکز هستند.

استفاده از HTTP/2 به‌صورت End-to-End

در صورت امکان Client، Front-end و Back-end همگی از HTTP/2 استفاده کنند.

PortSwigger این روش را یکی از مهم‌ترین اقدامات کاهش Request Smuggling معرفی می‌کند، زیرا HTTP/2 یک Mechanism مشخص برای تعیین طول Request دارد.

اما فقط فعال کردن HTTP/2 روی CDN کافی نیست.

باید مسیر Backend نیز بررسی شود.

جلوگیری از HTTP/2 Downgrade غیرضروری

اگر Front-end HTTP/2 دریافت و آن را به HTTP/1.1 تبدیل می‌کند، Translation Layer باید بسیار سخت‌گیرانه باشد.

در صورت امکان Backend Protocol نیز HTTP/2 باشد.

Reject کردن Request مبهم

Requestهای دارای:

Content-Length و Transfer-Encoding همزمان

Content-Lengthهای متناقض

Transfer-Encoding غیرقابل تفسیر

Header Syntax غیرمعتبر

نباید Normal Traffic تلقی شوند.

بستن Connection پس از Parsing Error

RFC 9112 در شرایط Ambiguous Message Framing بر بستن Connection تأکید می‌کند تا Data باقی‌مانده به‌عنوان Request بعدی تفسیر نشود.

Normalization در Front-end

Front-end باید قبل از Forward کردن Request:

Headerهای ناسازگار را Reject کند.

Representation را Canonical کند.

و Requestی واحد و بدون Ambiguity به Backend بفرستد.

Back-end نیز باید سخت‌گیر باشد

حتی اگر Front-end Validation دارد، Backend نباید Request مبهم را Accept کند.

PortSwigger توصیه می‌کند Front-end Request را Normalize کند و Back-end هر Ambiguity باقی‌مانده را Reject و Connection را Close کند.

آیا استفاده از یک Web Server یکسان کمک می‌کند؟

اگر Front-end و Back-end از Software و Configuration مشابه استفاده کنند، احتمال Parsing اختلافی می‌تواند کاهش یابد.

PortSwigger این کار را یکی از راه‌های کاهش Inconsistent Interpretation معرفی می‌کند.

اما این روش تضمین کامل نیست.

Versionها، Moduleها و Configurationها همچنان می‌توانند رفتار متفاوتی داشته باشند.

Patch و Update چرا مهم هستند؟

Request Smuggling تاریخچه طولانی از CVEهای مرتبط با:

Web Server

Proxy

Runtime

Framework

دارد.

MITRE برای CWE-444 نمونه‌هایی از مشکلات واقعی در Proxyها و Platformها ثبت کرده است.

بنابراین موارد زیر باید به‌روز باشند:

Reverse Proxy

Load Balancer

Web Server

HTTP Library

Runtime

CDN Agent

Gateway

و Middleware.

غیرفعال کردن Connection Reuse کافی است؟

خیر.

عدم Reuse کردن Backend Connection می‌تواند Impact برخی Desync Scenarioها را کاهش دهد، زیرا Requestهای کاربران مختلف کمتر روی یک Connection مشترک قرار می‌گیرند.

اما PortSwigger تأکید می‌کند این روش تمام انواع Request Smuggling و Request Tunnelling را رفع نمی‌کند.

بنابراین این کار Fix اصلی محسوب نمی‌شود.

WAF برای جلوگیری از Request Smuggling کافی است؟

خیر.

اگر WAF و Backend دقیقاً همان Parser اختلافی را داشته باشند، WAF بخشی از مشکل است.

WAF می‌تواند Headerهای مشکوک را Reject کند، اما Prevention واقعی نیازمند:

RFC-compliant Parsing

Strict Normalization

و Consistent Interpretation

در کل زنجیره است.

آیا Rate Limiting جلوی Request Smuggling را می‌گیرد؟

نه.

Rate Limiting می‌تواند Volume حمله را کاهش دهد، اما Root Cause Message Parsing را اصلاح نمی‌کند.

Request Smuggling ممکن است با تعداد بسیار کمی Request نیز اثر امنیتی داشته باشد.

چگونه HTTP Request Smuggling را به شکل دفاعی بررسی کنیم؟

Testing این Vulnerability می‌تواند Request Queue و کاربران واقعی را تحت تأثیر قرار دهد.

به همین دلیل تست عملی باید فقط روی:

Staging

Lab

Test Environment

یا سامانه‌ای که مجوز صریح دارید

انجام شود.

در Production بهتر است ابتدا:

Configuration Review

Version Review

RFC Compliance

Log Analysis

و Safe Scanner Mode

استفاده شود.

OWASP نیز HTTP Request Smuggling را در WSTG به‌عنوان یک موضوع تخصصی Web Security Testing پوشش می‌دهد.

بررسی معماری قبل از تست

اولین قدم رسم Request Path است.

مثلاً:

Internet

→ Cloudflare

→ HAProxy

→ Nginx

→ Application

مشخص کنید:

هر Hop از چه HTTP Versionی استفاده می‌کند؟

آیا Protocol Downgrade وجود دارد؟

کجا TLS Terminate می‌شود؟

کجا Connection Reuse وجود دارد؟

کدام Layer WAF دارد؟

کدام Layer Header را Rewrite می‌کند؟

بدون این اطلاعات پیدا کردن Root Cause دشوار است.

چه Logهایی می‌توانند نشانه مشکل باشند؟

هیچ Log Pattern واحدی اثبات Request Smuggling نیست.

اما موارد زیر نیازمند بررسی هستند:

افزایش 400 Bad Request

Connection Reset غیرعادی

Requestهای ناقص در Backend Log

Routeهایی که Front-end Log ندارد ولی Backend ثبت کرده

Mismatch بین تعداد Requestهای Proxy و Backend

Unexpected Method

Unexpected Path

User Requestهایی که Response اشتباه دریافت کرده‌اند

Cache Behavior غیرعادی

Header Parsing Error

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

مقایسه Log لایه‌ها

یکی از بهترین روش‌های دفاعی این است که Request ID میان تمام Layerها منتقل شود.

مثلاً:

CDN

Reverse Proxy

Application

همگی Correlation ID مشترک داشته باشند.

اگر Backend Requestی Log کند که هیچ Request ID متناظری در Front-end ندارد، این اتفاق باید بررسی شود.

Observability قوی می‌تواند Detection را بسیار ساده‌تر کند.

Canonical Request Logging

در Infrastructure حساس می‌توان Headerهای مهم Request را بعد از Normalization به صورت Structured Log ثبت کرد.

هدف ثبت Secretها نیست.

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

Authorization Token

Full Cookie

Password

در Log ذخیره شوند.

اما Metadata لازم برای تشخیص Parsing Anomaly بسیار مفید است.

آیا 400 Bad Request رفتار خوبی است؟

برای Request Ambiguous، Reject کردن بهتر از Guess کردن است.

یک Parser امن نباید تلاش کند Message مبهم را با حدس Developer تفسیر کند.

Fail Closed در اینجا اهمیت دارد.

اگر Request Protocol-invalid است:

Reject

Close Connection

Log Event

اغلب رفتار مناسب‌تری است.

تفاوت Normalization و Sanitization

Normalization در این Context یعنی Request به Representation استاندارد و بدون Ambiguity تبدیل شود.

مثلاً:

Header Format canonical شود.

Duplicate ناسازگار Reject شود.

Message Length واضح باشد.

Sanitization معمولاً به حذف Character یا Data خطرناک اشاره دارد.

برای Request Smuggling، Normalization و Reject کردن Syntax مبهم اهمیت بیشتری دارند.

امنیت Header Parser

Header Parser باید Strict باشد.

مواردی مانند:

Whitespace غیرعادی

Header Name نامعتبر

Newline غیرمنتظره

Duplicate Header

Colon Placement غیرمجاز

نباید توسط یک Component Allow و توسط دیگری متفاوت تفسیر شوند.

PortSwigger هنگام HTTP/2 Downgrade نیز توصیه می‌کند Request بازنویسی‌شده با قواعد HTTP/1.1 Validation شود.

آیا HTTP/3 موضوع Request Smuggling را تمام می‌کند؟

مهاجرت به Protocol جدید به‌تنهایی تضمین امنیت نیست.

هر جا یک Protocol در Edge به Protocol دیگری در Backend تبدیل شود، Translation Boundary باید Audit شود.

اصل اصلی ثابت است:

یک Message باید در تمام مراحل زنجیره یک Interpretation واحد داشته باشد.

بنابراین حتی در معماری‌های جدید، Parser Consistency و Protocol Translation همچنان Security Requirement هستند.

Request Smuggling در Kubernetes

در Kubernetes Request ممکن است از:

Cloud Load Balancer

Ingress Controller

Service Mesh

Application Server

عبور کند.

یعنی تعداد Parserها حتی بیشتر از معماری سنتی باشد.

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

Ingress از چه HTTP Versionی استفاده می‌کند؟

Backend Protocol چیست؟

Service Mesh Headerها را Rewrite می‌کند؟

Connection Pooling چگونه است؟

آیا چند Ingress Layer روی هم قرار گرفته؟

هر Hop اضافه باید دلیل معماری مشخص داشته باشد.

Microserviceها و Request Smuggling

در Microservice Architecture معمولاً North-South Traffic از Gateway عبور می‌کند.

اما Gateway ممکن است Request را به Service دیگری Forward کند.

اگر Parsing Rules یکسان نباشند، همان مشکل کلاسیک می‌تواند ظاهر شود.

Service داخلی نباید فرض کند Request چون از Gateway آمده، حتماً Safe است.

API Gateway و Backend Trust

یکی از اشتباهات رایج این است:

«فقط Gateway از Internet قابل دسترس است، پس Backend نیاز به Security ندارد.»

در عمل Gateway می‌تواند:

Misconfiguration

Parser Bug

SSRF

Request Smuggling

یا Credential Compromise

داشته باشد.

Backend باید Security Controlهای حیاتی خود را حفظ کند.

اشتباهات رایج در جلوگیری از HTTP Request Smuggling

اشتباه اول: فقط نصب WAF

WAF جای اصلاح Parser Consistency را نمی‌گیرد.

اشتباه دوم: HTTP/2 فقط روی CDN

اگر Backend HTTP/1.1 است، Downgrade Boundary همچنان وجود دارد.

اشتباه سوم: اعتماد به Proxy برای Authorization

Backend نیز باید Access Control داشته باشد.

اشتباه چهارم: قبول Request مبهم

Server نباید تلاش کند تمام Requestهای غیرقانونی را «بفهمد».

اشتباه پنجم: استفاده از Backend بسیار قدیمی

Legacy Parser ممکن است با Proxy مدرن رفتار متفاوت داشته باشد.

اشتباه ششم: چند Layer Proxy بدون مستندسازی

پیچیدگی بیشتر احتمال Interpretation Conflict را افزایش می‌دهد.

اشتباه هفتم: Disable کردن Connection Reuse به‌عنوان Fix نهایی

این کار فقط بعضی Scenarioها را کاهش می‌دهد.

اشتباه هشتم: تست مخرب روی Production

Request Smuggling می‌تواند Request دیگر کاربران را تحت تأثیر قرار دهد.

اشتباه نهم: نداشتن Correlation ID

Investigation Incident بسیار دشوارتر می‌شود.

اشتباه دهم: Update کردن فقط Application

گاهی Root Cause در Proxy یا Load Balancer است.

Secure Architecture برای جلوگیری از Request Smuggling

یک معماری مقاوم باید چند اصل داشته باشد.

کم کردن تعداد HTTP Parserها

هر Component اضافی Attack Surface ایجاد می‌کند.

اگر Proxy دوم واقعاً لازم نیست، حذف آن معماری را ساده‌تر می‌کند.

استفاده از Protocol یکسان

اگر ممکن است Protocol در Front-end و Backend یکسان باشد.

Strict Parsing

هر Component باید HTTP Specification را سخت‌گیرانه اجرا کند.

Reject Ambiguity

Requestهای چندتفسیری Reject شوند.

Backend Authorization

Controlهای حیاتی در Backend نیز اجرا شوند.

Observability

تمام Layerها Correlation ID و Log قابل مقایسه داشته باشند.

Patch Management

HTTP Infrastructure مرتب به‌روز شود.

چک‌لیست بررسی HTTP Request Smuggling

معماری

• تمام Proxyها و Gatewayها شناسایی شده‌اند.
• HTTP Version هر Hop مشخص است.
• نقاط HTTP/2 Downgrade مشخص شده‌اند.
• TLS Termination Point مشخص است.
• Connection Reuse مستند است.
• Component غیرضروری حذف شده است.

HTTP Parsing

• Request دارای Content-Length و Transfer-Encoding همزمان Reject می‌شود.
• Duplicate Content-Length متناقض Reject می‌شود.
• Transfer-Encoding نامعتبر Reject می‌شود.
• Header Syntax نامعتبر Reject می‌شود.
• Whitespace و Newline غیرمجاز Reject می‌شوند.
• Request Body Length دقیق Validate می‌شود.

Front-end

• Requestهای مبهم Normalize یا Reject می‌شوند.
• Headerها پیش از Forward شدن Canonical هستند.
• Protocol Conversion تست شده است.
• Security Policy تنها به WAF وابسته نیست.

Back-end

• Request Ambiguous پذیرفته نمی‌شود.
• Parsing Error باعث Connection Close می‌شود.
• Endpointهای حساس Authorization دارند.
• Backend به Front-end IP به‌تنهایی اعتماد نمی‌کند.
• Server و Runtime به‌روز هستند.

HTTP/2

• امکان HTTP/2 End-to-End بررسی شده است.
• Downgradeهای غیرضروری حذف شده‌اند.
• HTTP/2-to-HTTP/1 Conversion تست شده است.
• Length Validation هنگام Conversion انجام می‌شود.

Cache

• Cache Layer مشخص است.
• Cache Keyها مستندند.
• رفتار Cache با Requestهای غیرعادی تست شده است.
• Responseهای حساس بدون نیاز Cache نمی‌شوند.

Monitoring

• Correlation ID بین Layerها وجود دارد.
• Proxy و Backend Log قابل مقایسه‌اند.
• Parsing Error Monitor می‌شود.
• افزایش 400ها Alert مناسبی دارد.
• Request/Response Mismatch بررسی می‌شود.

مدیریت سیستم

• CDN به‌روز است.
• Load Balancer Patch شده است.
• Reverse Proxy Patch شده است.
• Web Server Patch شده است.
• HTTP Libraryهای Application به‌روز هستند.

چک‌لیست مخصوص WordPress و WooCommerce

اگر سایت WordPress دارید:

• مسیر CDN تا WordPress مستند شود.
• مشخص شود Nginx و Apache همزمان استفاده می‌شوند یا خیر.
• Configuration Reverse Proxy بررسی شود.
• Origin Server مستقیم از Internet قابل دسترس نباشد مگر با دلیل.
• Web Server و Proxy به‌روز باشند.
• WAF تنها Access Control سایت نباشد.
• /wp-admin/ و REST API در Application نیز Permission Check داشته باشند.
• HTTP/2 فقط در Edge بررسی نشود؛ Backend Protocol نیز مشخص شود.
• Cache Plugin و Server Cache با CDN هماهنگ باشند.
• Logهای CDN، Proxy و WordPress قابل Correlate باشند.
• Errorهای غیرعادی 400/502/503 بررسی شوند.
• WooCommerce Checkout و Account Endpointها برای Authorization صحیح بازبینی شوند.

تست امنیت Request Smuggling چگونه انجام شود؟

Request Smuggling یکی از Vulnerabilityهایی است که Testing اشتباه آن می‌تواند روی سایر کاربران اثر بگذارد.

به همین دلیل Test حرفه‌ای باید:

با مجوز انجام شود.

روی Staging ترجیح داده شود.

از Traffic واقعی جدا باشد.

تحت Monitoring انجام شود.

امکان Reset Connection داشته باشد.

Cache Production را آلوده نکند.

هدف Test باید اثبات Parser Inconsistency باشد، نه ایجاد Impact روی کاربران واقعی.

تست Configuration بدون Exploit

در بسیاری از موارد نیازی نیست Request واقعی Smuggle شود.

می‌توان بررسی کرد:

Proxy با Message مبهم چه می‌کند؟

Backend همان Message را چگونه Reject می‌کند؟

آیا هر دو Response 400 می‌دهند؟

آیا Connection بسته می‌شود؟

آیا Header ناسازگار قبل از Backend حذف می‌شود؟

این نوع Verification برای محیط Production امن‌تر است.

آیا Scanner به‌تنهایی کافی است؟

نه.

Request Smuggling به Architecture وابسته است.

Scanner ممکن است:

False Positive

یا False Negative

داشته باشد.

Security Engineer باید:

Topology

Protocol Version

Proxy Behavior

Connection Reuse

و Backend Parsing

را نیز بفهمد.

Incident Response در صورت مشاهده Request Smuggling

اگر احتمال Vulnerability یا Exploitation وجود دارد:

ابتدا Traffic مشکوک را Preserve کنید.

Logها را نگه دارید.

Version Componentها را ثبت کنید.

Request Path را مستند کنید.

Origin Server را در صورت نیاز محدود کنید.

Component آسیب‌پذیر Patch یا Reconfigure شود.

Connectionهای Persistent قدیمی Reset شوند.

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

Tokenها در صورت شواهد Exposure Rotate شوند.

سپس Retest انجام شود.

آیا Restart Server مشکل را حل می‌کند؟

Restart ممکن است Connectionهای Desynchronized را پاک کند، اما Vulnerability را اصلاح نمی‌کند.

اگر Parser اختلافی باقی مانده باشد، Attack دوباره ممکن است.

Restart فقط Recovery موقت است.

Fix اصلی Configuration یا Software Update است.

آیا HTTPS از Request Smuggling جلوگیری می‌کند؟

خیر.

HTTPS ارتباط را Encrypt می‌کند.

اما پس از TLS Termination، HTTP Request همچنان باید Parse شود.

اگر Reverse Proxy و Backend درباره Message Boundary اختلاف داشته باشند، TLS این اختلاف را حل نمی‌کند.

HTTPS ضروری است، اما Anti-Smuggling Mechanism نیست.

آیا CSP از Request Smuggling جلوگیری می‌کند؟

خیر.

Content Security Policy در Browser اجرا می‌شود و عمدتاً Resource Loading و Script Execution را کنترل می‌کند.

Request Smuggling یک Server-side Protocol Parsing Issue است.

CSP ممکن است Impact بعضی Client-side Attackها را کاهش دهد اما Root Cause را برطرف نمی‌کند.

آیا CORS جلوی Request Smuggling را می‌گیرد؟

خیر.

CORS Browser Policy برای Cross-Origin Response Sharing است.

Request Smuggling می‌تواند کاملاً بدون Browser یا Cross-Origin Request اتفاق بیفتد.

این دو Mechanism ارتباط مستقیمی ندارند.

آیا CSRF Token جلوی Request Smuggling را می‌گیرد؟

خیر.

CSRF Token برای جلوگیری از Requestهای ناخواسته Cross-site طراحی شده است.

Request Smuggling در HTTP Framing اتفاق می‌افتد.

البته Endpoint حساس باید همچنان CSRF Protection مناسب خود را داشته باشد.

Defenseها مکمل یکدیگر هستند.

آیا Request Smuggling در OWASP Top 10 قرار دارد؟

HTTP Request Smuggling در OWASP Top 10:2025 یک Category مستقل ندارد.

اما OWASP آن را در Web Security Testing Guide به‌صورت یک تست تخصصی با شناسه WSTG-INJT-16 پوشش می‌دهد و آن را نتیجه اختلاف Parsing میان Front-end و Back-end معرفی می‌کند.

CWE مرتبط نیز CWE-444 است.

سوالات متداول درباره HTTP Request Smuggling

HTTP Request Smuggling چیست؟

HTTP Request Smuggling آسیب‌پذیری‌ای است که در آن چند Component HTTP یک Request را با مرزهای متفاوت تفسیر می‌کنند و ممکن است بخشی از داده به‌عنوان Request جداگانه توسط Back-end پردازش شود.

نام فارسی HTTP Request Smuggling چیست؟

معمولاً از اصطلاح «قاچاق درخواست HTTP» یا «اسمگلینگ درخواست HTTP» استفاده می‌شود.

CWE مربوط به Request Smuggling چیست؟

CWE-444 یا Inconsistent Interpretation of HTTP Requests/Responses است.

دلیل اصلی Request Smuggling چیست؟

اختلاف میان HTTP Parserهای مختلف درباره محل پایان یک Request و شروع Request بعدی.

Content-Length چه نقشی دارد؟

Content-Length تعداد Byteهای Body را مشخص می‌کند و یکی از Mechanismهای HTTP/1.1 برای Message Framing است.

Transfer-Encoding چه نقشی دارد؟

Transfer-Encoding نحوه Coding پیام در انتقال را مشخص می‌کند و Chunked Transfer Coding در HTTP/1.1 می‌تواند برای Message Delimiting استفاده شود.

آیا یک Request باید Content-Length و Transfer-Encoding را همزمان داشته باشد؟

طبق RFC 9112 Sender نباید این دو Header را همزمان در یک Message ارسال کند. وجود هر دو می‌تواند Ambiguous و مرتبط با Request Smuggling باشد.

CL.TE چیست؟

حالتی است که Front-end از Content-Length برای تعیین Request Boundary استفاده می‌کند و Back-end از Transfer-Encoding.

TE.CL چیست؟

حالتی است که Front-end Transfer-Encoding را مبنا می‌گیرد و Back-end Content-Length را.

HTTP Desync چیست؟

وضعیتی است که دو Server در یک Connection درباره Position مرز Requestها با یکدیگر Synchronize نیستند.

آیا HTTP/2 جلوی Request Smuggling را می‌گیرد؟

اگر HTTP/2 واقعاً End-to-End باشد، Ambiguity کلاسیک HTTP/1 درباره Message Length حذف می‌شود. اما HTTP/2 Downgrade به HTTP/1 در Backend می‌تواند Attack Surface جدیدی ایجاد کند.

HTTP/2 Downgrade چیست؟

زمانی است که Front-end از Client Request HTTP/2 دریافت می‌کند اما آن را به HTTP/1.1 تبدیل کرده و به Backend می‌فرستد.

H2.CL چیست؟

نوعی اختلاف Request Boundary است که هنگام Translation HTTP/2 به HTTP/1 و استفاده Backend از Content-Length شکل می‌گیرد.

آیا WAF از Request Smuggling جلوگیری می‌کند؟

به‌تنهایی خیر. WAF ممکن است خودش یکی از Parserهای زنجیره باشد. Fix واقعی نیازمند Parsing یکسان و Reject کردن Requestهای Ambiguous است.

آیا HTTPS از Request Smuggling جلوگیری می‌کند؟

خیر. TLS Data را رمزگذاری می‌کند اما Parsing HTTP بعد از Decryption همچنان انجام می‌شود.

آیا Request Smuggling می‌تواند Cache را آلوده کند؟

در بعضی معماری‌ها بله. CWE-444 Cache Poisoning را یکی از پیامدهای ممکن معرفی می‌کند.

آیا Request Smuggling روی WordPress ممکن است؟

WordPress به‌خودی‌خود شرط Vulnerability نیست. اگر زیرساختی شامل CDN، Reverse Proxy و Web Server دارای Parsing ناسازگار باشد، سایت WordPress نیز می‌تواند پشت چنین زیرساختی قرار داشته باشد.

آیا Plugin وردپرس برای جلوگیری از آن کافی است؟

معمولاً خیر. Root Cause اغلب قبل از رسیدن Request به PHP و WordPress قرار دارد.

بهترین راه جلوگیری چیست؟

استفاده از HTTP/2 End-to-End در صورت امکان، حذف Downgrade غیرضروری، Strict Parsing، Reject کردن Requestهای Ambiguous، بستن Connection در Parsing Error و به‌روزرسانی تمام Proxyها و Web Serverها.

آیا غیرفعال کردن Keep-Alive مشکل را حل می‌کند؟

می‌تواند Impact بعضی Variantها را کاهش دهد اما Fix کامل نیست و همه انواع Request Smuggling را متوقف نمی‌کند.

آیا Request Smuggling فقط HTTP/1 است؟

انواع کلاسیک عمدتاً از HTTP/1 Message Framing استفاده می‌کنند، اما Translation میان HTTP/2 و HTTP/1 می‌تواند Vulnerabilityهای جدیدی مانند H2.CL و H2.TE ایجاد کند.

Request Smuggling چگونه تشخیص داده می‌شود؟

با Architecture Review، مقایسه Parser Behavior، Log Correlation، بررسی Protocol Translation و تست کنترل‌شده روی Environment مجاز.

آیا تست روی سایت اصلی خطرناک است؟

بله. Desynchronization ممکن است Request کاربران دیگر یا Cache را تحت تأثیر قرار دهد؛ بنابراین Staging یا Environment ایزوله گزینه مناسب‌تری است.

جمع‌بندی

HTTP Request Smuggling یکی از آسیب‌پذیری‌های پیچیده امنیت وب است، زیرا ضعف اصلی الزاماً داخل Source Code Application قرار ندارد.

ممکن است:

CDN کاملاً سالم باشد.

Reverse Proxy نیز به‌تنهایی سالم باشد.

Backend Server هم در شرایط عادی درست کار کند.

اما وقتی این Componentها کنار یکدیگر قرار می‌گیرند، اختلاف کوچک در HTTP Parsing می‌تواند یک Security Boundary خطرناک ایجاد کند.

اصل Request Smuggling ساده است:

دو Component درباره اینکه یک Request کجا تمام می‌شود توافق ندارند.

در HTTP/1.1 این اختلاف معمولاً حول:

Content-Length

Transfer-Encoding

Duplicate Header

یا Syntaxهای Ambiguous

رخ می‌دهد.

RFC 9112 برای جلوگیری از همین شرایط Ruleهای سخت‌گیرانه‌ای تعریف می‌کند و وجود همزمان Content-Length و Transfer-Encoding را مسئله‌ای جدی برای Message Framing می‌داند.

در معماری مدرن نیز HTTP/2 مسئله را کاملاً حذف نکرده است.

اگر HTTP/2 فقط بین Client و Front-end استفاده شود اما Front-end Request را به HTTP/1.1 Downgrade کند، Translation Boundary دوباره می‌تواند Parsing Ambiguity ایجاد کند.

به همین دلیل استفاده HTTP/2 End-to-End، در جایی که Architecture اجازه می‌دهد، یکی از روش‌های مهم کاهش Attack Surface محسوب می‌شود.

اما راهکار واقعی یک Control واحد نیست.

زنجیره HTTP باید به‌عنوان یک سیستم واحد طراحی شود.

Front-end باید Requestهای Ambiguous را Reject کند.

Back-end نیز باید Strict باشد.

Parsing Error نباید با Guess یا Recovery ناامن ادامه پیدا کند.

Connection مشکوک باید در شرایط لازم بسته شود.

Reverse Proxy، Load Balancer، CDN، WAF و HTTP Libraryها باید به‌روز باشند.

Authorization حیاتی باید در Backend انجام شود و به Filter موجود روی Proxy وابسته نباشد.

Observability نیز اهمیت زیادی دارد.

وقتی هر Request دارای Correlation ID باشد و Logهای CDN، Proxy و Application قابل مقایسه باشند، پیدا کردن رفتارهای غیرمنتظره بسیار ساده‌تر می‌شود.

در سایت WordPress و WooCommerce نیز همین اصل برقرار است.

افزونه امنیتی نمی‌تواند اختلاف Parsing میان CDN و Origin Server را حل کند.

مدیر سایت باید بداند Request قبل از رسیدن به WordPress از چه Layerهایی عبور می‌کند و در هر Hop از چه HTTP Version و Parserی استفاده می‌شود.

در نهایت HTTP Request Smuggling را می‌توان با یک اصل خلاصه کرد:

هر Byte از یک HTTP Request باید در تمام اجزای مسیر دقیقاً یک معنی داشته باشد.

اگر Front-end و Back-end نتوانند درباره مرز یک Request توافق کنند، آن اختلاف فقط یک Bug در Protocol Handling نیست؛ می‌تواند به یک مسیر عبور از مهم‌ترین کنترل‌های امنیتی سایت تبدیل شود.