Test HTTP Methods (fa-IR)

آزمایش روش های HTTP (فارسی)

خلاصه

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

ا RFC 7231 روش های اصلی درخواست معتبر HTTP (یا افعال) را تعریف می کند، اگرچه روش های اضافی در RFC های دیگر مانند RFC 5789 اضافه شده است. چندین مورد از این افعال برای اهداف مختلف در برنامه‌های RESTful، که در جدول زیر فهرست شده‌اند، دوباره استفاده شده‌اند.

اهداف آزمایش

• روش های HTTP پشتیبانی شده را برشمارید.
• آزمایش بای پس کنترل دسترسی.
• روش های غلبه بر روش HTTP را آزمایش کنید.

چگونه آزمایش کنیم

روش های پشتیبانی شده را کشف کنید (Discover the Supported Methods)

برای انجام این آزمایش، آزمایش کننده به روشی نیاز دارد تا تشخیص دهد کدام روش های HTTP توسط وب سروری که در حال بررسی است پشتیبانی می شود. ساده ترین راه برای انجام این کار، ارسال یک درخواست OPTIONS به سرور است:

OPTIONS / HTTP/1.1
Host: example.org

سپس سرور باید با لیستی از روش های پشتیبانی شده پاسخ دهد:

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST

با این حال، برخی از سرورها ممکن است به درخواست های OPTIONS پاسخ ندهند، یا ممکن است اطلاعات نادرست را برگردانند. علاوه بر این، سرورها ممکن است از روش‌های مختلفی برای مسیرهای مختلف پشتیبانی کنند - بنابراین فقط به این دلیل که یک روش برای دایرکتوری / ریشه (root) پشتیبانی نمی‌شود، لزوماً به این معنی نیست که در جای دیگری پشتیبانی نمی‌شود.

یک راه مطمئن تر برای آزمایش روش های پشتیبانی شده این است که به سادگی یک درخواست با آن نوع روش ارسال کنید و پاسخ سرور را بررسی کنید. اگر روش مجاز نباشد، سرور باید وضعیت 405 Method Not Allowed را برگرداند.

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

FOO / HTTP/1.1
Host: example.org

درخواست هایی با روش های دلخواه را می توان با استفاده از curl با گزینه X- نیز انجام داد:

curl -X FOO https://example.org

همچنین انواع مختلفی از ابزارهای خودکار وجود دارند که می توانند روش های پشتیبانی شده را تعیین کنند، مانند http-methods اسکریپت Nmap. با این حال، این ابزارها ممکن است روش‌های خطرناک را آزمایش نکنند (یعنی روش‌هایی که ممکن است باعث تغییراتی مانند PUT یا DELETE) شوند، یا در صورت پشتیبانی از این روش‌ها ممکن است ناخواسته تغییراتی در وب سرور ایجاد کنند. به این ترتیب، آنها باید با احتیاط استفاده شوند.

قرار دادن و حذف (PUT and DELETE)

متدهای PUT و DELETE بسته به اینکه توسط وب سرور تفسیر می شوند یا توسط برنامه ای که روی آن اجرا می شود، می توانند اثرات متفاوتی داشته باشند.

وب سرورهای قدیمی (Legacy Web Servers)

برخی از وب سرورهای قدیمی اجازه استفاده از روش PUT را برای ایجاد فایل روی سرور می دادند. برای مثال، اگر سرور به گونه‌ای پیکربندی شده باشد که این اجازه را بدهد، درخواست زیر فایلی را در سرور به نام test.html ایجاد می‌کند که حاوی محتویات <script>alert(1)</script> می باشد.

PUT /test.html HTTP/1.1
Host: example.org
Content-Length: 25

<script>alert(1)</script>

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

curl https://example.org --upload-file test.html

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

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

DELETE /test.html HTTP/1.1
Host: example.org

یا با cURL:

curl http://example.org/test.html -X DELETE

API های RESTful ‫(RESTful APIs)

در مقابل، روش‌های PUT و DELETE معمولاً توسط برنامه‌های RESTful مدرن برای ایجاد و حذف اشیا استفاده می‌شوند. به عنوان مثال، درخواست API زیر می تواند برای ایجاد کاربری به نام "foo" با نقش "user" استفاده شود:

PUT /api/users/foo HTTP/1.1
Host: example.org
Content-Length: 34

{
    "role": "user"
}

یک درخواست مشابه با روش DELETE می تواند برای حذف یک شی استفاده شود.

DELETE /api/users/foo HTTP/1.1
Host: example.org

اگرچه ممکن است توسط ابزارهای اسکن خودکار گزارش شود، وجود این روش ها در RESTful API یک مشکل امنیتی نیست. با این حال، این عملکرد ممکن است دارای آسیب‌پذیری‌های دیگری باشد (مانند کنترل دسترسی ضعیف)، و باید کاملاً آزمایش شود.

پی گیری (TRACE)

روش TRACE (یا معادل روش TRACK مایکروسافت) باعث می شود که سرور محتوای درخواست را بازتاب دهد. این منجر به آسیب‌پذیری به نام Cross-Site Tracing (XST) شد که در سال 2003 (PDF) منتشر شد، که می‌توان از آن برای دسترسی به کوکی‌هایی استفاده کرد که دارای پرچم HttpOnly هستند (flag set). روش TRACE سال‌هاست که در همه مرورگرها و افزونه‌ها مسدود شده است و به همین دلیل این مشکل دیگر قابل استفاده نیست. با این حال، ممکن است همچنان توسط ابزارهای اسکن خودکار علامت گذاری شود، و روش TRACE فعال شده در یک وب سرور نشان می دهد که به درستی سخت نشده است.

اتصال (CONNECT)

روش CONNECT باعث می شود وب سرور یک اتصال TCP را به سیستم دیگری باز کند و سپس ترافیک مشتری را به آن سیستم منتقل کند. این می تواند به مهاجم اجازه دهد تا ترافیک پروکسی را از طریق سرور، به منظور پنهان کردن آدرس منبع خود، دسترسی به سیستم های داخلی یا دسترسی به خدماتی که به لوکال هاست متصل هستند، انجام دهد. نمونه ای از یک درخواست CONNECT در زیر نشان داده شده است:

CONNECT 192.168.0.1:443 HTTP/1.1
Host: example.org

پچ (PATCH)

روش PATCH در RFC 5789 تعریف شده است و برای ارائه دستورالعمل‌هایی در مورد چگونگی تغییر یک شی استفاده می‌شود. خود RFC تعریف نمی‌کند که این دستورالعمل‌ها در چه قالبی باید باشند، اما روش‌های مختلفی در استانداردهای دیگر تعریف شده‌اند، مانند RFC 6902 - JavaScript Object Notation (JSON) Patch.

به عنوان مثال، اگر کاربری به نام "foo" با ویژگی های زیر داشته باشیم:

{
    "role": "user",
    "email": "foo@example.org"
}

درخواست JSON PATCH زیر می تواند برای تغییر نقش این کاربر "admin" بدون تغییر آدرس ایمیل استفاده شود:

PATCH /api/users/foo HTTP/1.1
Host: example.org

{ "op": "replace", "path": "/role", "value": "admin" }

اگرچه RFC بیان می‌کند که باید شامل دستورالعمل‌هایی برای نحوه اصلاح شی (object) باشد، روش PATCH معمولاً برای گنجاندن محتوای تغییر یافته استفاده می‌شود، همانطور که در زیر نشان داده شده است. مانند درخواست قبلی، این مقدار "role" را بدون تغییر بقیه شی به "admin" تغییر می‌دهد. این برخلاف روش PUT است که کل شی را بازنویسی می‌کند (و در نتیجه منجر به یک شی بدون ویژگی "email" می‌شود).

PATCH /api/users/foo HTTP/1.1
Host: example.org

{
    "role": "admin"
}

مانند روش PUT، این عملکرد ممکن است دارای ضعف های کنترل دسترسی یا آسیب پذیری های دیگر باشد. به‌علاوه، برنامه‌ها ممکن است در هنگام تغییر یک شی، همان سطح اعتبارسنجی ورودی را انجام ندهند که هنگام ایجاد آن انجام می‌دهند. این می تواند به طور بالقوه اجازه تزریق مقادیر مخرب را بدهد (مانند یک حمله اسکریپت نویسی بین سایتی ذخیره شده (stored cross-site scripting attack))، یا می تواند به اشیاء شکسته یا نامعتبر اجازه دهد که ممکن است منجر به مشکلات مربوط به منطق تجاری (business logic) شود.

آزمایش بای پس کنترل دسترسی (Testing for Access Control Bypass)

اگر صفحه ای در برنامه زمانی که کاربران تلاش می کنند و مستقیماً به آن دسترسی پیدا می کنند، به صفحه ورود با کد 302 هدایت می کند، ممکن است بتوان با درخواست با روش HTTP متفاوت، مانند HEAD، POST یا حتی یک روش ساخته شده مانند FOO، اگر برنامه وب با HTTP/1.1 200 OK به جای HTTP/1.1 302 Found مورد انتظار پاسخ دهد، ممکن است امکان دور زدن احراز هویت یا مجوز وجود داشته باشد. مثال زیر نشان می‌دهد که چگونه درخواست HEAD ممکن است منجر به تنظیم صفحه کوکی‌های مدیریتی به جای هدایت کاربر به صفحه ورود به سیستم شود:

HEAD /admin/ HTTP/1.1
Host: example.org

HTTP/1.1 200 OK
[...]
Set-Cookie: adminSessionCookie=[...];

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

HEAD /admin/createUser.php?username=foo&password=bar&role=admin HTTP/1.1
Host: example.org

یا:

FOO /admin/createUser.php
Host: example.org
Content-Length: 36

username=foo&password=bar&role=admin

آزمایش برای نادیده گرفتن روش HTTP ‫(Testing for HTTP Method Overriding)

برخی از چارچوب‌های وب راهی برای نادیده گرفتن روش HTTP واقعی در درخواست با شبیه‌سازی افعال HTTP از دست رفته و ارسال سرصفحه سفارشی در درخواست‌ها ارائه می‌کنند. هدف اصلی از این کار دور زدن یک برنامه میان افزاری (مانند فایروال پروکسی یا برنامه وب) است که روش های خاصی را مسدود می کند. هدرهای جایگزین HTTP زیر به طور بالقوه می توانند مورد استفاده قرار گیرند:

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

به منظور آزمایش این، در سناریوهایی که افعال محدود شده مانند PUT یا DELETE یک 405 Method not allowed را برمی‌گردانند، همان درخواست را با اضافه کردن سرصفحه‌های جایگزین برای نادیده گرفتن روش HTTP دوباره پخش کنید و مشاهده کنید که سیستم چگونه پاسخ می‌دهد. برنامه باید با یک کد وضعیت متفاوت پاسخ دهد (به عنوان مثال 200 OK) در مواردی که نادیده گرفتن روش پشتیبانی می شود.

وب سرور در مثال زیر به روش DELETE اجازه نمی دهد و آن را مسدود می کند:

DELETE /resource.html HTTP/1.1
Host: example.org

HTTP/1.1 405 Method Not Allowed
[...]

پس از افزودن هدر X-HTTP-Method، سرور با 200 به درخواست پاسخ می دهد:

GET /resource.html HTTP/1.1
Host: example.org
X-HTTP-Method: DELETE

HTTP/1.1 200 OK
[...]

اصلاح

• مطمئن شوید که فقط روش های مورد نیاز مجاز هستند و روش های مجاز به درستی پیکربندی شده اند.
• اطمینان حاصل کنید که هیچ راه حلی برای دور زدن اقدامات امنیتی اجرا شده توسط عوامل کاربر، چارچوب ها یا سرورهای وب اجرا نمی شود.

ابزارها

• Ncat
• cURL
• Nmap http-methods NSE script

منابع

• RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1)
• RFC 5789 - PATCH Method for HTTP
• HTACCESS: BILBAO Method Exposed
• Fortify - Misused HTTP Method Override
• Mozilla Developer Network - Safe HTTP Methods