اخبار داخلی آرمان داده پویان

مقالات

آسیب پذیری HTTP request smuggling

آسیب پذیری HTTP request smuggling

در ادامه مطالب آموزشی در ارتباط با امنیت وب، امروز به بررسی حملات HTTP request smuggling خواهیم پرداخت. در قسمت قبلی از سری مقالات آموزشی به بررسی پروتکل HTTP از دیدگاه امنیت پرداختیم و آن را به عنوان یکی از پایه‌ای ترین مفاهیم مورد استفاده در حوزه تست نفوذ وب معرفی کردیم. در مطلبی که پیش رو دارید ابتدا ساختار رایج مورد استفاده  برنامه‌های کاربردی وب بنیان (وب اپلیکیشن‌ها)، سپس علت به وجود آمدن آسیب پذیری HTTP request smuggling، حملات امنیتی‌ای که با استفاده از این آسیب پذیری رخ می‌دهد و در آخر نحوه برطرف کردن این آسیب پذیری خطرناک را مطرح خواهیم کرد.

چرا آسیب پذیری HTTP request smuggling به وجود می‌آید؟

ساختار رایجی که در حال حاضر بسیاری از برنامه‌های وب بنیان از آن بهره می‌گیرند استفاده از یک سرور front-end و چندین سرور back-end می‌باشد. سرور front-end که به آن reverse proxy یا load balancer نیز گفته می‌شود در سمت کاربر قرار داشته و زمانی که درخواست‌ها را از کاربران دریافت می‌کند، آن‌ها را به سمت سرورهای back-end که در سمت برنامه کاربردی هستند ارسال می‌کند. زمانی که سرور front-end چند درخواست http را از چند کاربر مختلف دریافت می‎‌نماید، بعد از انتخاب سرور back-end یک اتصال TCP با آن برقرار می‌کند. در پروتکل HTTP 1.1 که در حال حاضر به صورت گسترده‌ای در حال استفاده است، سرآیندی به نام connection وجود دارد که اگر مقدار آن keep alive در آن قرار داده شود این اتصال بعد از ارسال یک درخواست HTTP از بین نمی‌رود و به اصطلاح زنده می‌ماند. مزیت اصلی این کار کم شدن سربار (overhead) سرور می‌باشد و این امکان را برای سرور به وجود می‌آورد که از یک اتصال مثل یک لوله (pipeline) استفاده کرده و چندین درخواست را به سمت سرور back-end ارسال نماید بدون آنکه زمانی را در انتظار دریافت پاسخ تلف کند. حال باید مکانیزمی وجود داشته باشد تا سرور گیرنده انتهای هر درخواست وشروع درخواست بعدی را تشخیص دهد. دو سرآیند Content-Length و Transfer-Encoding به همین منظور در ساختار درخواست HTTP وجود دارند. می‌توان وجود دو سرآیند به صورت هم زمان و دیگری امکان ارسال چندین درخواست HTTP بر روی یک ارتباط TCP را علل اصلی به وجود آمدن این آسیب پذیری دانست.

چرا آسیب پذیری HTTP request smuggling به وجود می‌آید؟

مطابق با RFC قرار دادن مقدار برای هر دو سرآیند Content-Length و  Transfer-Encoding غیر مجاز است. اما این غیر مجاز بودن دلیل بر آن نمی‌شود که وب سرورها با این موضوع برخورد نکنند پس بایستی مکانیزمی وجود داشته باشد که اگر هر دو سرآیند مقدار دهی شده بوند، سرور یکی از آن‌ها را در نظر نگیرد. اگر تنها با یک سرور روبه رو بودیم این موضوع باعث ایجاد هیچ گونه مشکلی نمی‌شد اما زمانی که مانند مدلی که در قسمت اول تشریح کردیم با زنجیره‌ای از سرورها روبه رو هستیم اگر اختلافی بین این دو سرور برای در نظر گرفتن یکی از این دو سرآیند وجود داشته باشد آسیب پذیری HTTP request smuggling به وجود می‌آید که مهاجمین با استفاده از آن‌ کارهای متعددی از جمله دور زدن کنترل های امنیتی، به راه اندازی حملات cache poisoning، هک کردن حساب‌های کاربری و غیره خواهد شد. در ادامه سه حالت کلی که در آن‌ها این آسیب پذیری ایجاد خواهد شد را با جزئیات بررسی خواهیم کرد.

بررسی سرآیندهای Content-Length و Transfer-Encoding

سرآیند Content-Length  همان طور که از نامش پیداست طول پیغام را مشخص می‌کند. به طور مثال اگر برای آن مقدار ۱۳ قرار داده شده است یعنی درخواست HTTP، ۱۳ بایت بوده و بعد از ۱۳ بایت تمام شده و درخواست بعدی آغاز می‌گردد. سرآیند دیگر که در HTTP 1.1 پشتیبانی می‌گردد، سرآیند Transfer-Encoding می‌باشد، این سرآیند از مفهوم chunked encoding استفاده می‌کند یعنی داده‌ها را تکه تکه کرده و ارسال می‌کند. این سرآیند از سه بخش تشکیل شده است. در قسمت اول طول سرآیند به صورت یک عدد هگزا دسیمال، دوم بدنه سرآیند و در آخر عدد ۰ که پایان سرآیند را اعلام می‌نماید.

b
q=body
۰

در قسمت قبلی با هر دو سرآیند آشنا شدیم، حال اگر مهاجمی هر در درخواست ارسالی‌اش هر دو را مقدار داده باشد در سه حالت زیر می‌تواند با استفاده از آسیب پذیری HTTP request smuggling حملات امنیتی به راه بیندازد:

  • CL-TE : یعنی در سمت front-end سرآیند Content-Length و در سمت back-end سرآیند Transfer-Encoding در نظر گرفته شود.
  • TE-Cl: یعنی در سمت front-end سرآیند Transfer-Encoding و در سمت back-end سرآیند Content-Length در نظر گرفته شود.
  • TE-TE: در این حالت هر دو طرف سرآیند Transfer-Encoding را پشتیبانی می‌نمایند اما مهاجم با مبهم سازی سرآیند Transfer-Encoding کاری می‌کند تا یکی از سرورها پیغام قاچاق شده (smuggled) را پردازش ننماید.

آسیب پذیری CL-TE

برای شرح این وضعیت یک درخواست HTTP را بررسی می‌کنیم.

POST / HTTP/1.1

Host: vulnerable-website.com

Content-Length: 13

Transfer-Encoding: chunked

۰

SMUGGLED

در این سناریو، سمت فرستنده سرآیند Content-Length در نظر گرفته می‌شود، در نتیجه زمانی که وب سرور این درخواست را پردازش می‌کند، طول پیام را ۱۳ بایت در نظر گرفته و تا آخر SMUGGLED را پردازش کرده و درخواست را به سمت back-end ارسال می‌کند. اما در سمت back-end سرآیند Transfer-Encoding در نظر گرفته می‌شود و بعد از پردازش این سرآیند چون عدد صفر آورده شده است، برایش مشخص می‌گردد که این درخواست به آخر رسیده، در نتیجه SMUGGLED را پردازش نکرده و به عنوان شروع درخواست بعدی در نظر می‌گیرد. (این توضیحات تنها یک توضیح کلی راجع به این آسیب پذیری بود، در حالت واقعی یک مهاجم در این قسمت سناریوهای متعددی می‌تواند به راه بیندازد، از این رو است که آسیب پذیری HTTP request smuggling آسیب پذیری مهمی به حساب می‌آید.)

TE-CL

در حالت بعدی سمت فرستنده سرآیند Transfer-Encoding بررسی می‌گردد و در سمت گیرنده سرآیند Content length. در درخواست HTTPای که در پایین آورده شده است، سرور گیرنده بعد از پارس کردن سرآیند Transfer-Encoding تا آخر پیغام را پردازش کرده و آن را به سمت سرور back-end ارسال می‌کند. در سمت گیرنده که سرآیند Content-length پارس می‌شود، تنها سه بایت پردازش شده و درخواست SMUGGLED به عنوان درخواست بعدی در نظر گرفته می‌شود.

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

۸
SMUGGLED
۰

TE-TE

در این حالت هر دو سمت سرآیند 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 request smuggling

همانطور که در این مطلب، آسیب‌پذیری HTTP request smuggling را توضیح دادیم، این آسیب پذیری زمانی به وجود می‌آید که سرورfront-end بر روی یک ارتباط TCP چندین درخواست HTTP را ارسال می‌کند.

  • در نتیجه یکی از راهکارها ارسال هر درخواست HTTP بر روی یک ارتباط است که البته این موضوع بایستی بررسی گردد و بعد پیاده سازی شود چون باعث ایجاد سربار بر روی سرور می‌شود.
  • استفاده از یک نوع نرم افزاروب سرور در هر دو سمت front-end و back-end می‌باشد.
  • استفاده از HTTP/2 برای ارتباطات back-end

راهکارهایی که در بالا آوردیم در صورت پیاده سازی از ایجاد این آسیب پذیری جلوگیری می‌نماید.  آرمان داده پویان با ده سال تجربه و بهره گیری از تیم متخصصین تست نفوذ و برنامه نویسی خدمات ارزشمندی را در راستای تست نفوذ وب اپلیکیشن و امنیت وب به شما ارائه خواهد داد.

آرمان داده پویان ارائه دهنده تست نفوذ وب اپلیکیشن

برای مشاوره با کارشناسان ما تماس بگیرید

تعداد بازدید: 157


تازه ترین ها