WSTG-CONFIG-006

بررسی متدهای HTTP

در این بخش از دوره آموزشی OWASP-WSTG به دومین بخش از استاندارد WSTG با شناسه WSTG-CONFIG-006 می پردازیم که مربوط به بررسی متدهای HTTP می باشد.

خلاصه

HTTP تعدادی از متدها را ارائه می‌دهد که می‌توانند برای انجام عملیات بر روی وب سرور استفاده شوند.

‏استاندارد HTTP نسخه ۱.۱ به آن‌ها به عنوان Method اشاره می‌کند اما آن‌ها همچنین به عنوان Verb نیز شناخته می‌شوند.

در حالی که GET و POST رایج‌ترین متدهایی هستند که برای دسترسی به اطلاعات ارائه‌شده توسط یک وب سرور مورد استفاده قرار می‌گیرند،HTTP دارای متدهای دیگری نیز هست که تا حدودی کم‌تر شناخته ‌شده‌اند. اگر وب سرور به درستی پیکربندی نشده باشد، برخی از این موارد را می‌توان برای اهداف انحرافی مورد استفاده قرار داد.

RFC7231 متدهای HTTP معتبر زیر را تعریف می‌کند:

GET
HEAD
POST
PUT
DELETE
CONNECT
OPTIONS
TRACE

با این حال، بسیاری از برنامه‌های کاربردی وب تنها نیاز به پاسخ به درخواست‌های GET وPOST، دارند. هنگام استفاده از یک تگ a در HTML و استفاده از href در آن که ارسال به URL را فراهم می کند، در واقع متد GET استفاده شده و زمانی که داده‌ها از طریق یک فرم ارسال می‌شود که در آن نوع متد برابر POST در نظر گرفته شده است، ارسال درخواست‌ها به صورت POST می‌باشد.

آشنایی با WSTG-CONFIG-005

لازم به ذکر است که فراخوانی‌های JavaScript و Aajx ممکن است روش‌هایی به غیر از GET و POST را مورد استفاده قرار دهند اما معمولا نیازی به این کار نیست. از آنجا که روش‌های دیگر به ندرت مورد استفاده قرار می‌گیرند، بسیاری از توسعه دهندگان نمی‌دانند و یا نمی‌توانند در نظر بگیرند، استفاده نامناسب از این متدها می‌تواند بر ویژگی‌های امنیتی برنامه تاثیر بگذارد.

اهداف تست

شناسایی متدهای HTTP پشتیبانی شده
بررسی Bypass کنترل‌های دسترسی
بررسی آسیب‌پذیری XST
بررسی تکنیک HTTP Method Overriding

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

شناسایی متدهای پشتیبانی شده

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

انجام این تست می تواند به صورت دستی یا با استفاده از اسکریپت های Nmap انجام شود.

این کار با استفاده از دستور زیر در ابزار Nmap انجام خواهد شد:

هنگام بررسی یک برنامه که باید روش‌های دیگر را بپذیرد، به عنوان مثال یک وب سرویس RESTful ، آن را کاملاً بررسی نمایید تا اطمینان حاصل کنید که تمام Endpoint ها فقط متدهای مورد نیاز را می‌پذیرند.

بررسی متد PUT

• در این بخش می توان، درخواست ارسالی به هدف را با یک پروکسی وب بررسی نمایید.
• متد را در درخواست، به PUT تغییر داده و فایل test.html را اضافه نموده و درخواست را به سرور ارسال نمایید.

• اگر سرور با کدهای 2xx یا تغییر مسیر 3xx پاسخ دهد و سپس فایل test.html توسط درخواست GETتایید شود، برنامه آسیب‌پذیر می‌باشد.

اگر متد PUT براساس URL یا درخواست مجاز نیست، مسیرهای دیگر را در سیستم امتحان نمایید.

نکته: اگر اقدام به آپلود یک web shell در این مرحله نمودید، باید اطمینان حاصل نمایید که تیم امنیتی برنامه هدف، از این موضوع آگاه هستند و بلافاصله پس از اثبات مفهوم (POC)، آن را حذف نمایید.

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

تست عبور از کنترل دسترسی

صفحه‌ای را پیدا کنید که دارای یک محدودیت امنیتی باشد به طوری که شما را به صفحه لاگین هدایت نموده و یا به صورت مسقیم از شما اطلاعات احراز هویت را درخواست کند. درخواست‌هایی را با متدها مختلف مانند HEAD، POST،PUT و غیره ارسال نمایید.

همچنین از موارد دلخواه نیز می‌توان به جای متدهای معمول استفاده نمود.(BILBAO,CATS و غیره) اگر برنامه وب با یک HTTP/1.1 200 OK به شما پاسخ داده و صفحه لاگین نیز نبود، ممکن است امکان عبور از احراز هویت میسر باشد. در مثال زیر از ncat برای این کار استفاده شده است:

اگر سیستم آسیب‌پذیر به نظر برسد، شما می‌توانید حملاتی مشابه CSRF را بر روی هدف پیاده سازی نمایید. بدین منظور پیشنهاد می‌شود که برای بهره‌برداری کامل‌تر از این مساله از موارد زیر استفاده نمایید:

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

بررسی آسیب‌پذیری Cross Site Tracing

توجه: به منظور درک منطق و اهداف یک حمله XST، باید با حملات XSS آشنا باشید.

متد TRACE که برای تست و اشکال‌زدایی (Debugging) در نظر گرفته شده‌است، به وب سرور دستور می‌دهد تا پیام دریافتی را به کلاینت بازگرداند. این متد، در حالی که به ظاهر بی‌ضرر به نظر می‌رسد، می‌تواند با موفقیت در برخی از سناریوها برای سرقت Credential کاربران قانونی به کار گرفته شود.

این تکنیک حمله توسط Jeremiah Grossman در سال ۲۰۰۳ در تلاش برای دور زدن ویژگی HTTP Only کشف شد که هدف آن محافظت از کوکی‌ها در برابر دسترسی به وسیله JavaScript است. با این حال، روش TRACE را می‌توان برای عبور از این حفاظت و دسترسی به کوکی حتی زمانی که این ویژگی تنظیم شده ‌باشد، استفاده نمود.

جهت بررسی اینکه که سایت مورد نظر نسبت به XST آسیب‌پذیر است یا خیر می‌توان از دستور زیر استفاده نمود:

همانطور که در تصویر بالا نیز قابل مشاهده می باشد، وب سرور یک صفحه با کد ۲۰۰ را برگردانده و هدر تصادفی (Random: Header) را که در جای خود تنظیم شده ‌بود، منعکس نموده است. برای بهره‌برداری بیشتر از این آسیب‌پذیری موارد زیر مناسب می‌باشد:

مثال بالا در صورتی اجرا خواهد شد که پاسخ، در متن HTML منعکس شده ‌باشد.

در مرورگرهای قدیمی‌تر، حملات با استفاده از تکنولوژی XHR انجام می‌شد و هنگامی که سرور آن‌ها را منعکس می‌نمود، هدرها افشا می‌شدند (‏به عنوان مثال کوکی‌ها، توکن‌های مجوز و غیره)‏ و این موضوع منجر به نادیده گرفته شدن اقدامات امنیتی مانند ویژگی HTTP Only می‌گردید.

این حمله را تنها در صورتی می‌توان در مرورگرهای اخیر انجام داد که برنامه با فناوری‌های مشابه با Flash ادغام شده باشند.

بررسی HTTP Method Overriding

برخی از فریم ورک‌های وب، راهی را برای Override نمودن متدهای اصلی HTTP در یک درخواست بوسیله الگوبرداری از HTTP Verb های از دست رفته ارائه می‌دهند که برخی از هدرهای سفارشی را در درخواست‌ها منتقل می کند.

هدف اصلی این کار، عبور از محدودیت‌های میان افزارهایی مانند فایروال یا پروکسی می‌باشد که در آن‌ها متدهای مجاز معمولا متدهایی مانند PUT یا DELETE را شامل نمی‌شوند. برای انجام تونل‌هایی که از طریق آن بتوان این متدها را جابجا نمود، می‌توان از موارد زیر استفاده نمود:

• X-HTTP-Method
• X-HTTP-Method-Override
• X-Method-Override

به منظور تست موارد مذکور، در سناریوهایی که محدودیت در ارسال متدهای PUT یا DELETE وجود دارد و عبارت “405 Method not allowed” بازگشت داده می‌شود، همان درخواست‌ها را با اضافه کردن بخشی در هدر، مجددا ارسال نموده و نتایج را بررسی می‌نماییم.

در صورت وجود آسیب‌پذیری و امکان تغییر در متدها، برنامه با کدهای وضعیت متفاوتی از قبل به درخواست ما پاسخ می‌دهد.
در مثال زیر وب سرور، متد DELETE را مجاز نمی‌داند و آن را مسدود نموده است:

اما پس از اضافه نموده X_HTTP_Header به هدر، پاسخ سرور تغییر نموده و کد وضعیت 200 را باز می‌گرداند:

Remediation

اطمینان حاصل نمایید که تنها هدرهای مورد نیاز مجاز بوده و همچنین هدرهای مجاز به درستی پیکربندی شده باشند.

اطمینان حاصل نمایید که هیچ راهکاری برای عبور از اقدمات امنیتی اعمال شده توسط User-agent، Framework یا وب سرور وجود نداشته باشد.

ابزارها

• Ncat
• cURL
• nmap http-methods NSE script
• w3af plugin htaccess_methods

منابع

• RFC 2109 and RFC 2965: “HTTP State Management Mechanism”
• HTACCESS: BILBAO Method Exposed
• Amit Klein: “XS(T) attack variants which can, in some cases, eliminate the need for TRACE”
• Fortify – Misused HTTP Method Override
• CAPEC-107: Cross Site Tracing