وقتی ما با یک سایت کار میکنیم، معمولاً درخواستهایمان مستقیماً به سرور اصلی نمیرسند. در بسیاری از زیرساختهای مدرن، قبل از رسیدن درخواست به سرور اصلی، یک Reverse Proxy، CDN یا Load Balancer آن را دریافت و پردازش میکند.
در نگاه اول این موضوع ساده به نظر میرسد؛ کاربر درخواست را ارسال میکند، Reverse Proxy آن را دریافت میکند و سپس به سرور اصلی تحویل میدهد. اما همینجا جایی است که یکی از جالبترین آسیبپذیریهای وب شکل میگیرد.
در نسخههای اولیه HTTP، برای هر درخواست یک اتصال TCP جدید ایجاد میشد. اگر یک صفحه وب شامل چند فایل CSS، JavaScript و تصویر بود، مرورگر مجبور میشد برای هر کدام یک اتصال جدید برقرار کند. این موضوع از نظر Performance اصلاً مناسب نبود.
برای حل این مشکل در HTTP/1.1 قابلیتهایی مثل Keep-Alive معرفی شدند تا چندین درخواست بتوانند از یک اتصال مشترک استفاده کنند.
اما وقتی چند درخواست روی یک اتصال ارسال میشوند، سرور باید بتواند تشخیص دهد هر درخواست از کجا شروع میشود و کجا به پایان میرسد.
یکی از رایجترین روشها استفاده از هدر Content-Length است.
این هدر به سرور میگوید که چه مقدار داده در بخش Body وجود دارد. به زبان ساده، سرور میفهمد که بعد از هدرها باید چه تعداد بایت را بخواند و سپس درخواست را تمامشده در نظر بگیرد.
اما تنها راه موجود نیست.
روش دیگری به نام Transfer-Encoding: chunked نیز وجود دارد.
در این حالت داده به صورت چند بخش جداگانه ارسال میشود. هر بخش اندازه خودش را مشخص میکند و در نهایت با یک Chunk پایانی، پایان پیام مشخص میشود.
برخلاف Content-Length که از همان ابتدا اندازه کل داده مشخص است، در Chunked دادهها مرحله به مرحله ارسال میشوند.
به همین دلیل زمانی که از Chunked استفاده میشود، منطق تشخیص پایان درخواست با حالت معمول متفاوت خواهد بود.
مشکل زمانی به وجود میآید که در مسیر پردازش درخواست، بیش از یک سرور وجود داشته باشد.
فرض کنید درخواست ابتدا به Reverse Proxy برسد و سپس به سرور اصلی ارسال شود.
اگر Reverse Proxy و سرور اصلی درباره نحوه تشخیص پایان درخواست با یکدیگر اختلاف نظر داشته باشند، شرایط برای ایجاد HTTP Request Smuggling فراهم میشود.
در واقع هر دو سرور یک درخواست را دریافت میکنند، اما ممکن است آن را به شکل متفاوتی تفسیر کنند.
همین اختلاف تفسیر باعث میشود بخشی از دادهها به شکل غیرمنتظره وارد صف درخواستهای بعدی شوند.
به همین دلیل به این آسیبپذیری Request Smuggling یا «قاچاق کردن درخواست» گفته میشود.
در این سناریو Reverse Proxy بر اساس Content-Length تصمیم میگیرد، اما سرور اصلی Transfer-Encoding را معتبر میداند.
در نتیجه هر کدام مرز پایان درخواست را متفاوت تشخیص میدهند.
در این سناریو Reverse Proxy بر اساس Transfer-Encoding تصمیم میگیرد، اما سرور اصلی Content-Length را معتبر میداند.
این اختلاف در تفسیر باعث میشود هر دو سرور برداشت متفاوتی از یک درخواست داشته باشند.
در این حالت هر دو سرور از Transfer-Encoding استفاده میکنند، اما نحوه پردازش آنها یکسان نیست و همین موضوع میتواند باعث ایجاد رفتارهای غیرمنتظره شود.
HTTP Request Smuggling به تنهایی شاید خیلی هیجانانگیز به نظر نرسد، اما قدرت اصلی آن زمانی مشخص میشود که با سایر آسیبپذیریها ترکیب شود.
در تحقیقات امنیتی مختلف از این آسیبپذیری برای مواردی مثل:
Cache Poisoning
Session Hijacking
دور زدن مکانیزمهای احراز هویت
افشای اطلاعات کاربران
دسترسی به صفحات داخلی
استفاده شده است.
به همین دلیل بسیاری از شرکتهای بزرگ فناوری توجه ویژهای به این دسته از آسیبپذیریها دارند.
تا حد زیادی بله.
در HTTP/2 ساختار پردازش درخواستها تغییر کرده و بسیاری از مشکلات کلاسیک Request Smuggling دیگر به شکل گذشته وجود ندارند.
اما در عمل هنوز هم ممکن است بخشی از زیرساخت از HTTP/1.1 استفاده کند. برای مثال ارتباط میان Reverse Proxy و Backend Server ممکن است همچنان بر پایه HTTP/1.1 باشد.
به همین دلیل Request Smuggling هنوز هم یکی از موضوعات مهم در تست نفوذ وب و برنامههای Bug Bounty محسوب میشود.
برخلاف بسیاری از آسیبپذیریهای شناختهشده وب، HTTP Request Smuggling معمولاً به خاطر یک خطای ساده در کدنویسی به وجود نمیآید. ریشه این مشکل در اختلاف نحوه پردازش درخواستها بین اجزای مختلف زیرساخت است؛ جایی که Reverse Proxy یک درخواست را به شکلی تفسیر میکند و Backend Server همان درخواست را به شکل دیگری میفهمد.
همین اختلاف کوچک میتواند زمینهساز حملات پیچیدهای مانند Cache Poisoning، Session Hijacking یا حتی دور زدن مکانیزمهای امنیتی شود.
به همین دلیل HTTP Request Smuggling را میتوان یکی از آسیبپذیریهایی دانست که برای درک آن باید فراتر از کد برنامه نگاه کرد و نحوه تعامل اجزای مختلف زیرساخت وب را شناخت.
اگر در حوزه تست نفوذ وب یا Bug Bounty فعالیت میکنید، آشنایی با این آسیبپذیری میتواند دید بهتری نسبت به نحوه پردازش درخواستها و رفتار واقعی سرورها به شما بدهد.
