جعل درخواست سمت سرور (SSRF)

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

SSRF چیست؟

جعل درخواست سمت سرور (همچنین به عنوان SSRF نیز شناخته می شود) یک آسیب پذیری امنیت وب است که به یک مهاجم اجازه می دهد تا برنامه سمت سرور را القا کند تا درخواست هایی را برای یک مکان ناخواسته ایجاد کند.

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

آزمایشگاهها

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

تأثیر حملات SSRF چیست؟

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

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

حملات مشترک SSRF

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

حمله SSRF به خود سرور

در حمله SSRF علیه خود سرور ، مهاجم برنامه را القا می کند تا درخواست HTTP را از طریق رابط شبکه Loopback خود به سرور میزبان برنامه بازگرداند. این به طور معمول شامل تهیه URL با یک نام میزبان مانند 127. 0. 0. 1 (یک آدرس IP رزرو شده که به آداپتور loopback اشاره دارد) یا LocalHost (یک نام متداول برای همان آداپتور) است.

به عنوان مثال ، یک برنامه خرید را در نظر بگیرید که به کاربر اجازه می دهد مشاهده کند که آیا یک مورد در یک فروشگاه خاص موجود است یا خیر. برای ارائه اطلاعات سهام ، برنامه باید API های مختلف استراحت پشتی را که به محصول و فروشگاه مورد نظر وابسته است ، پرس و جو کند. این عملکرد با انتقال URL به نقطه انتهایی API Back-end از طریق درخواست HTTP جلوی آن اجرا می شود. بنابراین وقتی کاربر وضعیت سهام را برای یک مورد مشاهده می کند ، مرورگر آنها درخواستی را مانند این ارائه می دهد:

پست/محصول/سهام HTTP/1. 0 نوع محتوا: برنامه/x-www-form-urlencoded طول محتوا: 118 StockApi = http: //stock. weliketoshop.net: 8080/product/stock/check ٪ 3fproductid ٪ 3d6 ٪26storeid ٪ 3D1

این امر باعث می شود سرور درخواستی را به URL مشخص شده ، بازیابی وضعیت سهام و بازگرداندن این کار به کاربر ارائه دهد.

در این شرایط ، یک مهاجم می تواند درخواست را برای مشخص کردن یک URL محلی به خود سرور تغییر دهد. مثلا:

پست/محصول/سهام HTTP/1. 0 نوع محتوا: برنامه/x-www-form-urlencoded طول محتوا: 118 StockApi = http: // localhost/admin

در اینجا ، سرور محتویات URL /Admin را واکشی می کند و آن را به کاربر باز می گرداند.

البته ، مهاجم فقط می تواند مستقیماً از URL /مدیر سرپرست بازدید کند. اما عملکرد اداری معمولاً فقط برای کاربران معتبر مناسب قابل دسترسی است. بنابراین یک مهاجم که به سادگی از URL بازدید می کند مستقیماً مورد علاقه خود را نمی بیند. با این حال ، هنگامی که درخواست URL /Admin از خود دستگاه محلی می آید ، کنترل های دسترسی عادی از آن دور می شوند. این برنامه دسترسی کامل به عملکرد اداری را اعطا می کند ، زیرا به نظر می رسد این درخواست از یک مکان قابل اعتماد سرچشمه می گیرد.

Apprentice Basic SSRF در برابر سرور محلی

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

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

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

حمله SSRF به سایر سیستم های پشتی

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

در مثال قبلی ، فرض کنید یک رابط اداری در URL Back-end https://192. 168. 0. 68/admin وجود دارد. در اینجا ، یک مهاجم می تواند با ارسال درخواست زیر از آسیب پذیری SSRF برای دسترسی به رابط اداری سوء استفاده کند:

پست/محصول/سهام HTTP/1. 0 نوع محتوا: برنامه/x-www-form-urlencoded طول محتوا: 118 StockApi = http: //192. 168. 0. 68/admin

Apprentice Basic SSRF در برابر یک سیستم پشتی دیگر

دور زدن دفاعی مشترک SSRF

معمول است که برنامه های حاوی رفتار SSRF را همراه با دفاع با هدف جلوگیری از بهره برداری مخرب مشاهده کنیم. اغلب ، این دفاع ها می توانند دور شوند.

SSRF با فیلترهای ورودی مبتنی بر لیست سیاه

برخی از برنامه ها ورودی حاوی نام های میزبان مانند 127. 0. 0. 1 و LocalHost یا URL های حساس مانند /مدیر را مسدود می کنند. در این شرایط ، شما اغلب می توانید با استفاده از تکنیک های مختلف فیلتر را دور بزنید:

• با استفاده از نمایندگی جایگزین IP از 127. 0. 0. 1 ، مانند 2130706433 ، 017700000001 یا 127. 1.
• ثبت نام دامنه خود را که به 127. 0. 0. 1 برطرف می شود ، ثبت کنید. برای این منظور می توانید از spoofed. burpcollaborator.net استفاده کنید.
• رشته های مسدود شده با استفاده از رمزگذاری URL یا تغییر مورد.

پزشک SSRF با فیلتر ورودی مبتنی بر لیست سیاه

SSRF با فیلترهای ورودی مبتنی بر لیست سفید

برخی از برنامه ها فقط به ورودی اجازه می دهند که با یک لیست سفید از مقادیر مجاز مطابقت داشته باشد ، یا شامل می شود. در این شرایط ، گاهی اوقات می توانید با سوء استفاده از ناسازگاری در تجزیه URL ، فیلتر را دور بزنید.

مشخصات URL شامل تعدادی از ویژگی ها است که در هنگام اجرای تجزیه و تحلیل موقت و اعتبارسنجی URL ها از آنها غافل می شوند:

• با استفاده از کاراکتر @ می توانید اعتبارنامه ها را در URL تعبیه کنید. به عنوان مثال: https: // انتظار می رود: FakePassword@Evil-Host
• می توانید از # کاراکتر برای نشان دادن یک قطعه URL استفاده کنید. به عنوان مثال: https: // evil-host#انتظار می رود میزبان
• شما می توانید از سلسله مراتب نامگذاری DNS استفاده کنید تا ورودی مورد نیاز را در یک نام کاملاً واجد شرایط DNS که کنترل می کنید قرار دهید. به عنوان مثال: https: //expected-host. evil-host
• می توانید کاراکترهای URL را برای اشتباه گرفتن کد URL PARSING CONSED کنید. این امر به ویژه در صورتی مفید است که کدی که فیلتر را اجرا می کند ، شخصیت های رمزگذاری شده URL را متفاوت از کدی که درخواست HTTP پشتی را انجام می دهد ، کنترل می کند. توجه داشته باشید که می توانید شخصیت های دو رمزگذاری را نیز امتحان کنید. برخی از سرورها به صورت بازگشتی URL ورودی را دریافت می کنند ، که می تواند منجر به اختلافات بیشتر شود.
• می توانید از ترکیب این تکنیک ها با هم استفاده کنید.

SSRF متخصص با فیلتر ورودی مبتنی بر لیست سفید

بیشتر بخوانید

دور زدن فیلترهای SSRF از طریق تغییر مسیر باز

گاهی اوقات می توان هر نوع دفاعی مبتنی بر فیلتر را با بهره برداری از آسیب پذیری تغییر مسیر باز دور زد.

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

به عنوان مثال ، فرض کنید برنامه شامل یک آسیب پذیری تغییر مسیر باز است که در آن URL زیر:

تغییر مسیر به:

شما می توانید از آسیب پذیری تغییر مسیر باز برای دور زدن فیلتر URL استفاده کنید و از آسیب پذیری SSRF به شرح زیر بهره برداری کنید:

پست/محصول/سهام http/1. 0 محتوا از نوع: برنامه/x-www-form-urlencoded طول محتوا: 118 stockApi = http: //weliketoshop.net/product/nextproduct؟ جریان فعلی productid = 6 & path = http: //192. 168. 0. 68/مدیر

این بهره برداری SSRF کار می کند زیرا برنامه ابتدا تأیید می کند که URL StockAPI عرضه شده در یک دامنه مجاز است ، که در آن قرار دارد. سپس برنامه از URL عرضه شده درخواست می کند ، که باعث تغییر مسیر باز می شود. این تغییر مسیر را دنبال می کند و درخواست URL داخلی انتخاب مهاجم را می دهد.

پزشک SSRF با بای پس فیلتر از طریق آسیب پذیری تغییر مسیر باز

آسیب پذیری های SSRF کور

آسیب پذیری های کور SSRF هنگامی بوجود می آیند که یک درخواست برای صدور درخواست HTTP پشتی به URL عرضه شده ایجاد شود ، اما پاسخ از درخواست پشتی در پاسخ جلوی برنامه بازگردانده نمی شود.

SSRF کور به طور کلی استفاده از آن سخت تر است اما گاهی اوقات می تواند منجر به اجرای کامل کد از راه دور در سرور یا سایر اجزای پشتی شود.

بیشتر بخوانید

یافتن سطح حمله پنهان برای آسیب پذیری های SSRF

بسیاری از آسیب پذیری های جعلی درخواست سرور نسبتاً آسان است ، زیرا ترافیک عادی برنامه شامل پارامترهای درخواست حاوی URL های کامل است. نمونه های دیگر SSRF برای یافتن آن سخت تر است.

URL های جزئی در درخواست ها

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

URL های موجود در قالب های داده

برخی از برنامه ها داده ها را در قالب هایی منتقل می کنند که مشخصات آنها اجازه می دهد تا URL هایی را که ممکن است توسط تجزیه کننده داده برای قالب درخواست شود ، درج شود. نمونه بارز این قالب XML Data است که به طور گسترده در برنامه های وب برای انتقال داده های ساختار یافته از مشتری به سرور استفاده شده است. هنگامی که یک برنامه داده ها را با فرمت XML می پذیرد و آن را تجزیه می کند ، ممکن است در برابر تزریق XXE آسیب پذیر باشد و به نوبه خود از طریق XXE در برابر SSRF آسیب پذیر باشد. وقتی به آسیب پذیری های تزریق XXE نگاه می کنیم ، این موضوع را با جزئیات بیشتری می پوشانیم.

SSRF از طریق هدر مراجعه کننده

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

بیشتر بخوانید

آیا می خواهید پیشرفت خود را پیگیری کنید و تجربه یادگیری شخصی تری داشته باشید؟(رایگان است!)