HTTP request smuggling چیست؟ آشنایی با حملات قاچاق درخواست HTTP

ارسال شده توسط توسط sadegh_khan 13 دقیقه مطالعه

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

قاچاق http request چیست ؟

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

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

حائز اهمیت هست که HTTP request Smugglingابتدا سال ۲۰۰۵ مطرح شد و هم اکنون توسط تحقیقات PortSwigger’s مجدد مطرح شده است.

در حمله های 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 تفسیر شود. به طور مؤثر به درخواست بعدی اضافه می شود و در نتیجه می تواند در روشی که اپلیکیشن درخواست را پردازش می کند، دخالت کند.

چگونه آسیب پذیری های HTTP request smuggling رُخ می دهند؟

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

سربرگ content length ساده است: طول بدنه پیام (message body) را با بایت-Byte مشخص می کند. برای مثال: 

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

خیلی از تسترهای امنیتی به دو دلیل، از این که chunked encoding  می تواند در درخواست های HTTPاستفاده شود، بی اطلاع هستند.

  • 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 به نوعی و روشی، وادار کرد تا آن را پردازش نکند.

آسیب پذیری CL.TE :

در اینجا سرور front-end از سربرگ Content-Length استفاده می کند و سرور back-end از سربرگ  Transfer-Encoding استفاده می کند. می توان یک حمله (attack) قاچاق درخواست HTTPساده را به صورت زیر انجام داد:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

سرور front-end سربرگ Content-Length را پردازش می کند و تشخیص می دهد که بدنه ی درخواست (request body) دارای طول ۱۳ بایت باشد (تا پایان SMUGGLED ). این درخواست روی سرور back-end ارسال می شود.

سرور back-end سربرگ Transfer-Encoding را پردازش می کند و با بدنه پیام به عنوان رمزگذاری chunked رفتار می کند. chunk اول را پردازش می کند، که طول آن صفر عنوان شده است و درنتیجه به منزله خاتمه درخواست با آن رفتار می کند. بایت های بعدی، SMUGGLED، دست نخورده و پردازش نشده باقی می مانند و سرور backe-end با این ها به عنوان شروع یک درخواست جدید در توالی درخواست ها، رفتار می کند.

آسیب پذیری TE.CL:

در اینجا سرور front-end از سربرگ Transfer-Encoding استفاده می کند و سرور back-end از سربرگ Content-Length استفاده می کند. می توان یک حمله (attack) قاچاق درخواست HTTPساده را به صورت زیر انجام داد:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

سرور front-end سربرگ Transfer-Encoding را پردازش می کند، بنابراین با «بدنه پیام» به عنوان chunked encoding رفتار می کند. chunk اول را پردازش می کند، که با طول ۸ بایت معرفی شده است (تا شروع خط SMUGGLED ). سپس chunk دوم که با طول صفر مشخص شده را پردازش می کند و در نتیجه به عنوان خاتمه درخواست با آن رفتار می کند. این درخواست روی سرور back-endفوروارد می شود.

سرور back-end سربرگ Content-Length پردازش می کند و مشخص می کند که بدنه درخواست دراای طول ۳ بایت می باشد، تا شروع خطی که شامل ۸ است. بایتهای پیش رو، که با SMUGGLED شروع می شوند، پردازش نشده باقی می مانند و سرور back-end با آنها به عنوان شروع درخواست بعدی موجود در توالی رفتار می کند .

رفتارTE.TE : مبهم کردن سربرگ TE

اینجا هر جفت سرور های front-endو back-end از سربرگ Transfer-Encoding پشتیبانی می کنند، اما یکی از سرورها می تواند وادار شود که به روشی و با ابهام کردن سربرگ، آن را پردازش نکند.

اساسا راه های بیشماری برای مبهم کردن سربرگ Transfer-Encoding وجود دارد، برای مثال: 

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

هر کدام از این روشها شامل تغییری ظریف از مشخصات HTTPهستند. کد دنیای-واقعی که مشخصات پروتکل را پیاده سازی می کندبه ندرت با دقت کامل به آن پایبند است و برای پیاده سازی های متفاوت معمول است که دگرگونی مختلفی از مشخصات را تحمل کند.

برای کشف یک آسیب پذیری TE.TE لازم است برخی از تغییرات از سربرگ Transfer-Encoding به گونه ای که فقط یکی از سرور های front-end یا back-end آن را پردازش کند، و سرور دیگر آن را نادیده بگیرد، پیدا شود.

با توجه به اینکه سرور front-end است یا back-end که می تواند وادار شود Transfer-Encoding header مبهم شده را پردازش نکند، بقیه حمله ها فرمی مشابه با آسیب پذیری های CL.TE یا TE.CL که در ابتدا تشریح شد را خواهند داشت.

چطور از آسیب پذیری های HTTP request smuggling جلوگیری کنیم:

آسیب پذیری های HTTP request smuggling زمانی رخ می دهد که سرور front-end چندین درخواست را روی یک network connectionبه سمت سرور back-endبفرستد و پروتکل استفاده شده برای اتصالات سرور back-end، دارای ریسک اینکه دو سرور با هم در مورد مرزبندی بین درخواست ها توافق نداشته باشند، را دارا باشد.

بعضی از راه های عمومی برای جلوگیری از آسیب های قاچاق درخواست HTTP به شرح زیر می باشد:

  • غیر فعال کردن استفاده مجدد از connectionدر سرور back-end، بنابراین هر درخواست back-end روی یک network connection مستقل ارسال می شود.
  • استفاده از HTTP/2 برای اتصالات back-end، زیرا این پروتکل از ابهام در مورد مرزبندی بین درخواست ها جلوگیری می کند.
  • استفاده از دقیقا یک نرم افزار وب سرور مشابه برای سرورهای front-end و back-end ،در نتیجه آنها در مورد مرزبندی درخواست ها توافق خواهند داشت.

در بعضی از موارد می توان از آسیب پذیری ها با نرمالایز کردن درخواست های مبهم توسط سرور front-end یا reject کردن درخواست های مبهم توسط سرور back-endو بستن network connection ، پرهیز کرد.

منابع :

https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

https://blog.detectify.com/2020/05/28/hiding-in-plain-sight-http-request-smuggling/

https://portswigger.net/web-security/request-smuggling

https://snyk.io/blog/demystifying-http-request-smuggling/