سناریو حمله بر اساس Http Response Splitting

این حمله که تحت عنوان ” http response smuggling” نیز معروف است، در صورت وجود شرایط زیر، امکان پذیر است:

• دیتا از طریق یک untrusted source، به وب‌اپلیکیشن آسیب‌پذیر منتقل گردد؛ که عموما در قالب یک http request این موضوع انجام می‌شود.
• دیتای ارسال شده به وب‌اپلیکیشن آسیب‌پذیر، بدون آنکه بر روی کاراکترهایش validate ای صورت پذیرد، در http response header قرار گرفته و بسمت web user بازگردد.

بصورت کلی این حمله بسیار ساده انجام می‌شود: اتکر اطلاعاتی را به وب اپلیکیشن آسیب پذیر انتقال می‌دهد و در فاز دوم، وب اپلیکیشن، این اطلاعات را در http response header خود می‌گنجاند.
برای آنکه یک اکسپلویت موفق داشته باشیم، اپلیکیشن باید input های زیر را به عنوان ورودی‌های قابل قبول در هدر عبور دهد:
• Input های شامل کاراکترهای CR (Carriage Return, %0d or \r)
• Input های شامل کاراکترهای LF (Line Feed, %0a or \n)
همچنین پلت‌فرم مورد نظر نیز در برابر چنین کاراکترهایی اسیب پذیر باشد.

چنین کاراکترهایی از دو جهت به اتکرها کمک می‌کنند:
• به اتکرها این امکان را می‌دهند تا وجود آن‌ها را در response (header and body) ای که اپلیکیشن قصد ارسال آن را دارد، کنترل نماید.
• به اتکرهای این امکان را می‌دهند تا تحت کنترلی که دارند، response های بیشتری را ایجاد کنند.

هرچند که در مثال زیراز یک نمونه جاوا – یی – استفاده کردیم اما در حال حاضر این آسیب پذیری بر روی تمام اپلیکیشن سرورهای مدرن Java EE برطرف شده است. اگر نگران وجود این آسیب پذیری بر روی سیستم های خود هستید، باید تست کنید که پلت فرم مورد نظر شما در مقابل کاراکترهای CR یا LF تزریق شده به هدر، چه برخوردی را نشان می‌دهند.
در حالت کلی این انتظار می‌رود که این آسیب‌پذیری بر روی تمام اپلیکیشن‌ سرورهای مدرن – فارغ از این که کد با چه زبانی نوشته شده باشد – برطرف شده باشد.

مثال

قطعه کد زیر، ورودی مربوط به نام نویسنده وبلاگ ( author) را از یک http request می‌خواند و آن را در یک کوکی از کوکی های موجود در response قرار می‌دهد.

با توجه به قطعه کد بالا، به نظر می‌رسد رشته‌ای از کاراکترهای استاندارد “alpha-numeric”، مانند ” Ehsan Amjadi”، در request قابل قبول باشد؛ بنابراین با توجه به آنچه که در قطعه کد بالا تعریف شده است، response باید چنین فرمی داشته باشد:

در مثال بالا هرچند validate ای بر روی input وجود نداشت ولی به علت آن‌که مقدار ورودی (Ehsan Amjadi) فاقد کاراکترهای CR و LF بود، در Response اتفاق غیر منتظره ای دال بر حمله http response splitting شاهد نبودیم.
اما اگر اتکر در مقدار ورودی بجای یک رشته کاراکتر استاندارد مثل ” Ehsan Amjadi”، مقداری مانند
” Ehsan Hacker\r\nContent-Length:65\r\n\r\n…” را قرار دهد، با توجه به آن که در قطعه کد، validate ای بر روی آن صورت نمی‌گیرد، در response شاهده چنین فرمی خواهیم بود که نمایانگر موفقیت آمیز بودن حمله http response splitting است:

حال فرض کنید که در بین وب اپلیکیشن و اتکر، یک cache proxy server هم وجود داشته باشد؛ نتیجه این می‌شود که پروکسی سرور response برگشتی را cache کرده و بعد از این، به ازای تمام request های سرویس مورد نظر، response بالا را بر خواهد گرداند. این موضوع در ساده‌ترین حالت باعث deface شدن یک سایت خواهد شد. علاوه بر این باید گفت که این میزان توانایی اتکر در ایجاد فرم‌های مختلف در http response می‌تواند منجر به حملاتی چون:
Cache Poisoning, Cross-site Scripting (XSS) Cross-User Defacement, و Page Hijacking
گردد.

مانا باشید
احسان امجدی / کارشناس و مدرس دوره‌های تحلیل امنیت

“اگر بر این باورید که با نقض قانون کپیرایت، وضعیتی بهتر در انتظارمان خواهد بود، بدون ذکر نامِ نویسنده و منبع، مجاز به انتشار مطالب هستید. “