WSTG-INPV-04

بررسی HTTP Parameter Pollution

در این بخش از دوره آموزشی OWASP-WSTG به هفتمین بخش از استاندارد WSTG با شناسه WSTG-INPV-04 می پردازیم که مربوط به بررسی HTTP Parameter Pollution می باشد.

خلاصه

HTTP Parameter Pollution، برنامه‌های کاربردی را در پاسخ به دریافت چندین پارامتر HTTP با نام یکسان آزمایش می‌کند. به عنوان مثال، اگر پارامتر username دو بار در پارامترهای GET یا POST گنجانده شود.

ارائه پارامترهای HTTP چندگانه با یک نام ممکن است باعث شود که یک برنامه Value ها را به روش‌های پیش‌بینی‌نشده تفسیر کند. با توجه به اثرات HTTP Parameter Pollution، یک مهاجم ممکن است بتواند اعتبارسنجی ورودی را دور بزند، خطاهای برنامه را trigger کند یا مقادیر متغیرهای داخلی را اصلاح کند. همانطور که HTTP Parameter Pollution بر تمام بخش‌های تکنولوژی‌های وب تاثیر می گذارد، حملات سمت کلاینت یا سرور نیز در این بخش وجود خواهند داشت.

استانداردهای HTTP فعلی شامل راهنمایی در مورد چگونگی تفسیر پارامترهای ورودی چندگانه با یک نام نیستند. به عنوان مثال، RFC3986 به سادگی عبارت Query String را به عنوان یک سری از جفت‌های field-value تعریف می‌کند و RFC2396 کلاس‌هایی از کاراکترهای Query String معکوس و ذخیره نشده را تعریف می‌کند. بدون وجود استاندارد، اجزای برنامه کاربردی وب به روش‌های مختلفی با این لبه برخورد می‌کنند (‏جدولی که در ادامه قرار داده خواهد شد را برای مشاهده جزئیات بیشتر مطالعه نمایید)‏.

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

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

Input Validation and Filters Bypass

در سال ۲۰۰۹، بلافاصله پس از انتشار اولین تحقیق در مورد HPP، این تکنیک توجه جامعه امنیتی را به عنوان یک راه ممکن برای دور زدن فایروال‌های تحت وب جلب کرد.

یکی از این نقص‌ها، که بر ModSecurity SQL Injection Core Rules تاثیر می‌گذارد. فیلتر ModSecurity، ارسال درخواست:هایی که شامل دستورات SQL مانند دستور زیر باشد را مسدود نموده و اجازه اجرای آن را نخواهد داد.

بنابراین اگر عبارت بالا درURL وجود داشته باشد، از پردازش آن توسط سرور وب جلوگیری می‌شود.

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

یک آسیب‌پذیری HPP دیگر بر روی Apple Cups تاثیر می گذاشت که یک سیستم چاپ شناخته‌شده مورد استفاده بسیاری از سیستم‌های یونیکس بود. با استفاده از HPP، یک مهاجم می‌تواند به راحتی با استفاده از آدرس زیر، یک آسیب‌پذیری XSS را راه‌اندازی کند:

با اضافه کردن یک آرگومان kerberos اضافی که دارای یک رشته معتبر است (‏به عنوان مثال رشته خالی)‏، می‌توان نقطه کنترل اعتبار برنامه را دور زد. از آنجا که کنترل اعتبارسنجی تنها رخداد دوم را در نظر می‌گیرد، اولین پارامتر kerberos قبل از استفاده برای تولید محتوای HTML پویا به درستی Sanitize نشده است. بهره‌برداری موفق در این بخش، منجر به اجرای کد JavaScript در سایت خواهد شد.

Authentication Bypass

یک آسیب‌پذیری حتی مهم‌تر از نوع HPP در Blogger که یک پلتفرم وبلاگ نویسی محبوب می‌باشد، کشف شد. این مشکل به کاربران مخرب این امکان را می‌داد تا مالکیت وبلاگ قربانی را با استفاده از درخواست HTTP زیر به دست آورند.

این نقص در مکانیزم احراز هویت مورد استفاده برنامه وب قرار داشت، زیرا بررسی امنیتی در پارامتر اول blogID انجام می‌شد، در حالی که عملیات واقعی از رخداد دوم استفاده کرد.

Expected Behavior by Application Server

جدول زیر نشان می‌دهد که تکنولوژی‌های مختلف وب در هنگام حضور چندین اتفاق از یک پارامتر HTTP یکسان، از خود رفتار چه رفتاری نشان می‌دهند.

URL مورد نظر در این بخش example.com/?color=red&color=blue می‌باشد.

اهداف تست

• شناسایی Back-End و روش تجزیه مورد استفاده.
• نقاط تزریق را ارزیابی کنید و سعی کنید فیلترهای ورودی را با استفاده از HPP دور بزنید.

چگونه تست را انجام دهیم

خوشبختانه، چون تخصیص پارامترهای HTTP معمولا از طریق سرور برنامه کاربردی وب انجام می‌شود و نه خود برنامه کاربردی، آزمایش پاسخ به Parameter Pollution باید در تمام صفحات و اقدامات استاندارد باشد. با این حال، همانطور که شناخت منطق کسب‌وکار به شکل عمیق، نیاز به بررسی دستی دارد، بررسی HPP نیز می‌بایست به صورت دستی انجام شود. ابزارهای خودکار تنها تا حدی می‌توانند به حسابرسان کمک کنند زیرا امکان تولید False Positive در آن‌ها بسیار زیاد خواهد بود. علاوه بر این، HPP می‌تواند خود را در اجزای سمت کلاینت و همچنین سرور نشان دهد.

Server-Side HPP

برای تست آسیب‌پذیری‌هایHPP، هر فرم یا عملی که امکان دریافت ورودی توسط کاربر را فراهم می‌کند، شناسایی کنید. پارامترهای Query String در درخواست‌های HTTP GET به راحتی در نوار پیمایش مرورگر (Navigation Bar) قابل تنظیم و بررسی می‌باشند. اگر داده‌ها از طریق فرم‌هایی با متد POST ارسال شود، تست نفودگر باید از یک Intercepting Proxy برای دستکاری داده‌های POST که به سرور ارسال می‌شود، استفاده کند. برای آزمایش آسیب‌پذیری‌های HPP، کافی است همان پارامترهای شناسایی شده را به داده‌های GET یا POST اضافه کنید. ولی با این تفاوت که مقدار متفاوتی به آن‌ها اختصاص داده شود.

برای مثال: اگر در حال تست پارامتر search_string در Query String هستید،UR شما ممکن است به شکل زیر باشد:

این پارامتر خاص ممکن است در میان چندین پارامتر دیگر پنهان باشد، اما این رویکرد ما جهت تست، یکسان خواهد بود:

اضافه نمودن همان پارامتر با مقدار متفاوت:

و درخواست جدید را با اعمال تغییرات بالا، ارسال می‌کنیم.

صفحه پاسخ را تجزیه و تحلیل کنید تا مشخص شود که کدام مقادیر تجزیه شده‌اند. در مثال بالا، نتایج جستجو ممکن است kittens، puppies، ترکیبی از هر دو (‏kittens,puppies or kittens~puppies or [‘kittens’,’puppies’])‏ نشان داده شده و یا ممکن است نتیجه تهی یا صفحه خطا را نشان دهد.

این رفتار، چه استفاده از اولین، آخرین، یا ترکیبی از پارامترهای ورودی با همان نام، به احتمال زیاد در سراسر برنامه سازگار خواهد بود. این که آیا این رفتار پیش‌فرض یک آسیب‌پذیری بالقوه را آشکار می‌کند یا نه، به اعتبارسنجی ورودی خاص و فیلتر کردن خاص یک برنامه بستگی دارد. به عنوان یک قاعده کلی: اگر اعتبارسنجی ورودی موجود و دیگر مکانیزم‌های امنیتی بر روی ورودی‌های منفرد کافی باشند و اگر سرور تنها اولین یا آخرین پارامترهای آلوده را اختصاص دهد، Parameter Pollution، آسیب‌پذیری را نشان نمی‌دهد. اگر پارامترهای تکراری به‌هم‌پیوسته باشند، اجزای مختلف نرم‌افزار وب از رخدادهای مختلف استفاده ‌کنند یا تست یک خطا ایجاد ‌کند، احتمال بیشتری وجود دارد که بتوان از Parameter Pollution برای تحریک آسیب‌پذیری‌های امنیتی استفاده کرد.

یک تحلیل عمیق‌تر نیازمند سه درخواست HTTP برای هر پارامتر HTTP است:

یک درخواست HTTP حاوی نام و مقدار پارامتر استاندارد را ارسال کنید و پاسخ HTTP را ثبت کنید. مانند page?par1=val1

مقدار پارامتر را با یک مقدار دستکاری‌شده جایگزین کنید، درخواست را ارسال نموده و پاسخ HTTP را ثبت کنید. مانند page?par1=HPP_TEST1

یک درخواست جدید با ترکیب مرحله یک و دو ‏ارسال کنید. دوباره، پاسخ HTTP را ثبت کنید. مانند page?par1=val1&par1=HPP_TEST1

پاسخ‌های به‌دست‌آمده در طول تمام مراحل قبلی را مقایسه کنید. اگر پاسخ بخش سه ‏متفاوت از یک باشد و پاسخ بخش سه ‏نیز متفاوت از بخش دو ‏باشد، ممکن است این پارامترها در نهایت برای تحریک آسیب‌پذیری‌های HPP مورد سو استفاده قرار گیرند.

Client-Side HPP

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

برای تست آسیب‌پذیری‌های HPP سمت کلاینت، هر فرم یا عملی که امکان دریافت ورودی توسط کاربر را فراهم می‌کند، شناسایی کنید. در این بین، صفحه جستجو می‌تواند ایده‌آل باشد، اما صفحه ورود به سیستم ممکن است کار نکند (‏زیرا ممکن است نام کاربری نامعتبری را به کاربر نشان ندهد)‏.

مشابه HPP سمت سرور، هر پارامتر HTTP را با %26HPP_TEST آلوده کنید و به دنبال موارد رمزگشایی شده توسط URL مربوط به پیلود ارائه شده توسط کاربر باشید:

به طور خاص، به پاسخ‌های دارای بردارهای HPP درون data، src، href یا forms actions توجه کنید. دوباره باید به این نکته اشاره کنیم؛ اینکه آیا این رفتار پیش‌فرض آسیب‌پذیری بالقوه را آشکار می‌کند یا خیر، به اعتبارسنجی ورودی ، فیلتر کردن و منطق کسب‌وکار برنامه بستگی دارد. علاوه بر این، توجه به این نکته مهم است که این آسیب‌پذیری همچنین می‌تواند بر پارامترهای Query String مورد استفاده در XMLHttpRequest یا XHR، ایجاد ویژگی زمان اجرا و سایر فن‌آوری‌های متصل شونده (به عنوان مثال Adobe Flash’s flashvars variables) تاثیر بگذارد.

Tools

OWASP ZAP Passive/Active Scanners