آسیب پذیری HTTP request smuggling چیست؟

آسیب پذیری HTTP request smuggling چیست؟

HTTP request smuggling تکنیکی برای تداخل در نحوه پردازش توالی درخواست های HTTP از طریق یک یا چند کاربر می باشد. (به صورت خودمونی، یک یا چند تا کاربر دارند درخواست HTTPمی دند و بین این درخواست ها که توالی نیز دارند میخواهیم تداخل بوجود بیاریم)

آسیب پذیری های request smuggling (قاچاق درخواست) غالبا حیاتی هستند و به هکر این اجازه را می دهند که کنترل های امنیتی را دور بزند و به داده های حساس ما دسترسی پیدا کند و سایر کاربران برنامه را مستقیما به خطر بیاندازد.

در حمله های HTTP request smuggling چه اتفاقی می افتد؟

امروزه وب اپلیکیشن ها اکثرا از زنجیره ای از سرور ها بین کاربر نهایی و لاجیک برنامه استفاده می کنند. کاربران درخواست ها (request) را به سمت سرور front-end می فرستند (گاهی load balancer یا reverse proxyنیز نامیده می شود) و این سرور درخوسات ها را به سمت یک یا چند سرور back-end ارسال می کند. این نوع از معماری روز به روز در حال گسترش و رایج شدن می باشد و در بعضی از موارد اجتناب ناپذیر می باشد، مانند برنامه های ابری (cloud-based application ).

زمانی که سرور front-end درخواست (request) های HTTP را به سمت سرور Back-end هدایت می کند.، معمولا چندین درخوسات را روی یک ارتباط شبکه (network connection) مشابه که روی back-end ایجاد شده بوده می فرستند. چرا که این کار کارآمدتر و بهینه می باشد. پروتکل خیلی ساده است: HTTP request ها یکی پس از دیگری ارسال می شوند و سرور دریافت کننده header درخوسات های httpرا parse می کند تا تشخیص دهد کجا هر درخواست تمام می شود و درخواست بعدی شروع می شود.

در این موقعیت، بحث حیاتی اینجا است که front-end و back-end روی مرز بین درخواست (request)ها به توافق برسند. در غیر این صورت، حمله کننده (هکر) ممکن است بتواند یک درخواست مبهم که توسط سیستم های front-end و back-endمتفاوت تفسیر می شود را ارسال کند.

اینجا حمله کننده، باعث می شود که قسمتی از درخواست front-end به عنوان شروع درخواست بعدی توسط back-end تفسیر شود. به طور مؤثر به درخواست بعدی اضافه می شود و در نتیجه می تواند در روشی که اپلیکیشن درخواست را پردازش می کند، دخالت کند.

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

سربرگ Transfer-Encoding می تواند استفاده شود تا تشخیص دهد بدنه پیام از انکودینگ تکه ای (chunked encoding) استفاده می کند. به این معنی که بدنه پیام (message body) یک یا چند تکه از داده (chunks of data) را شامل می شود. هر چانک متشکل از سایز چانک به بایت (به صورت هگزادسیمال بیان شود) می باشد و همچنین به دنبال آن یک خط جدید می آید (New Line). پیام ارسال شده با چانکی با اندازه صفر به پایان می رسد. برای مثال:

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

• Burp Suite به صورت خودکار chunked encoding را باز کرده تا پیام برای مشاهده و ویرایش ساده باشد.
• مرورگرها به طور معمول از chunked encoding داخل درخواست ها استفاده نمی کنند و معمولا تنها در response های سرور دیده می شود.

از آنجا که مشخصات HTTP دو روش مختلف برای تعیین طول پیام های HTTP فراهم کرده اند، این ممکن است که یک پیام تنها، از دو روش با هم استفاده کند، به گونه ای که با یکدیگر تضاد داشته باشند و ناسازگار باشند. مشخصات HTTPسعی می کند تا با بیان اینکه اگر در سربرگ (header) هر دوی Content-Length و Transfer-Encoding حاضر هستند، باید سربرگ Content-Length در نظر گرفته نشود، از این مشکل جلوگیری کند.

این ممکن است برای رفع ابهام، هنگامی که تنها یک سرور در حال کارکردن است، کافی باشد، اما نه زمانی مکه دو یا چند سرور با یکدیگر در حال کار هستند. در این شرایط مشکلات به دو دلیل می توانند بوجود بیایند:

• بعضی از سرور ها از درخواست های با سربرگ Transfer-Encoding پشتیبانی نمی کنند.
• بعضی از سرور ها که از سربرگ Transfer-Encoding پشتیبانی می کنند می توانند منجر شوند که اگر سربرگ به هر طرقی مبهم بود، پردازش نشود.

اگر سرورهای front-end و back-end در رابطه با سربرگ Transfer-Encoding متفاوت رفتار کنند، در این صورت ممکن است بین مرزهای درخواست های مختلف اختلاف نظر داشته باشند که همین منجر به آسیب پذیری قاچاق درخواست (request smuggling vulnerabilities) می شود.

نحوه انجام حمله قاچاق درخواست HTTP

HTTP request smuggling attack، حمله قاچاق درخواست شامل قراردادن جفت سربرگ های Content-Length و Transfer-Encoding در یک HTTP request می باشد و با دستکاری کردن این دو، سرور های front-end و back-end با request بطور متفاوت رفتار کنند. روش دقیق برای انجام این عمل بستگی به رفتار هر دو سرور دارد:

• CL.TE : سرور front-end از Content-Length header  استفاده می کند و سرور back-end از  Transfer-Encoding header استفاده می کند.
• TE.CL :سرور front-end از Transfer-Encoding header  استفاده می کند و سرور back-end از Content-Length header استفاده می کند.
• TE.TE : هر جفت سرورهای front-end و back-end از Transfer-Encoding header  پشتیبانی می کنند، اما یکی از سرورها را می توان توسط مبهم کردن header به نوعی و روشی، وادار کرد تا آن را پردازش نکند.