حمله SSRF چیست؟ معرفی رایج‌ترین انواع آن

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

SSRF چیست؟

SSRF که مخفف Server-side request forgery می‌باشد، که در زبان فارسی جعل درخواست در سمت سرور ترجمه می‌شود.

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

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

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

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

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

حملات رایج SSRF

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

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

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

در یک حمله SSRF علیه خود سرور، فرد مهاجم با دست‌کاری و فریب اپلیکیشن آن را متقاعد می‌کند تا از طریق اینترفیس لوپ‌بک (کانال خود دریافت) سرور پیامی تحت عنوان درخواست HTTP به‌سوی خود سرور میزبان (درواقع خود اپلیکیشن) ارسال کند. در این فرایند آدرس‌های URL مورداستفاده برای ایجاد درخواست معمولاً حاوی hostnam مانند 127.0.0.1 یا localhost هستند.

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


POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

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


POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin


در این مرحله، سرور محتویات آدرس URL «/admin» را بازآوری می‌کند و به کاربر بازمی‌گرداند.

اکنون واضح است که فرد مهاجم صرفاً توانسته به طور مستقیم و بدون هیچ ترفندی به آدرس /admin دسترسی یابد و از آن دیدن کند. اما امکانات، قابلیت‌ها یا اقدامات مدیریتی معمولاً تنها برای کاربرانی در دسترس هستند که به شکل مورد انتظار احراز هویت شده باشند؛ بنابراین، فرد مهاجمی که به‌سادگی می‌تواند مستقیماً از آدرس مذکور دیدن کند، بدون احراز هویت لازم، هیچ اطلاعات معنی‌دار و جالب‌توجهی نخواهد دید. اما با تمام این اوصاف، هنگامی‌که درخواست به آدرس /admin از خود ماشین یا سرور محلی آمده باشد، به دلیل وجود اعتماد کنترل‌های دسترسی عادی دور زده خواهند شد. ازآنجایی‌که درخواست مذکور در ظاهر از مکانی مورداعتماد نشئت‌گرفته است، اپلیکیشن به فرد مهاجم دسترسی کامل و نامحدود به امکانات، قابلیت‌ها یا اقدامات مدیریتی را اعطا خواهد کرد. چرا این رفتار از اپلیکیشن‌ها سر می‌زد و چرا اپلیکیشن‌ها به درخواست‌هایی که از سوی ماشین یا سرور محلی می‌آیند، اعتماد غیرصریح (بی‌قیدوشرط) می‌کنند؟ این رفتار ممکن است دلایل متعددی داشته باشد:

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

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

حملات SSRF بر علیه سایر سیستم‌های back-end

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

فرض کنید که در مثال قبل، یک اینترفیس مدیریتی در پس آدرس https://192.168.0.68/admin مربوط به پشتیبان قرار دارد که در حال گوش‌دادن است. فرد مهاجم می‌تواند برای دسترسی به اینترفیس مدیریتی با ارسال درخواست زیر از آسیب‌پذیری SSRF در اپلیکیشن بهره‌برداری کند.

دورزدن مکانیزم‌های دفاعی رایج SSRF

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

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

برخی از اپلیکیشن‌ها ورودی‌های حاوی hostname مانند 127.0.0.1 و localhost یا URLهای حساس مانند 127.0.0.1 را مسدود می‌کنند. در این شرایط، اغلب اوقات می‌توان با استفاده از تکنیک‌های مختلف فیلتر را دور زد:

• از آدرس جایگزین IP برای 0.0.1 با فرمت هگزادسیمال یا شانزده‌شانزدهی 2130706433، با فرمت اکتال یا هشت‌هشتی 017700000001 و با فرمت دسیمال یا ده‌دهی 127.1 استفاده کنید.
• با خرید نام دامنه از فروشندگان دامنه و سپس پیکربندی رکوردهای DNS آن برای تبدیل نام به آدرس 0.0.1 که آدرس لوپ‌بک (خوددریافت) کامپیوتر به‌حساب می‌آید، محدودیت فیلتر IP را دور بزنید. برای این منظور، می‌توانید از نام دامنه‌ی آورده‌شده در انتهای این پاراگراف استفاده کنید که توسط برب‌سوئیت (ابزار تست امنیت اپلیکیشن‌های وب) ارائه شده است. این نام دامنه قبلاً برای تبدیل 127.0.0.1 پیکربندی‌شده است، بنابراین نیازی به ثبت و خرید آن نیست.spoofed.burpcollaborator.net

• با استفاده از روش رمزنگاری URL یا تنوع حروف به مبهم‌سازی یا به‌عبارت‌دیگر نهان‌سازی رشته‌های متنی مسدودشده توسط سیستم امنیتی بپردازید.
• یک آدرس URL تهیه کنید که به‌عنوان مالک کنترل کامل روی آن دارید. این آدرس متعاقباً باید به آدرس URL نهایی موردنظر شما یا هدف تغییر مسیر دهد. سعی کنید برای تغییر مسیر از کدهای مختلف تغییر مسیر موسوم به کدهای HTTP status استفاده کنید. همچنین برای تغییر مسیر به URL هدف از پروتکل‌های مختلف مانند پروتکل HTTP یا HTTPS استفاده کنید. مشاهده شده است که با تغییر پروتکل آدرس URL از http: به https: در حین تغییر مسیر می‌توان برخی از فیلترهای امنیتی طراحی‌شده برای جلوگیری از حملات جعل درخواست در سمت سرور را دور زد.

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

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

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

• با استفاده از کاراکتر @، می‌توان اطلاعات احراز هویت مانند نام کاربری و رمز عبور را قبل از hostname در آدرس URL گنجاند. مثلاً:


https://username:password@hostname.com


• برای نشان‌دادن جزء URL می‌توان از کاراکتر # استفاده کرد. برای مثال، جزء #contact بخش تماس صفحه‌ی وب را مشخص می‌کند.


https://evil-host#expected-host


• برای گنجاندن ورودی موردنیاز در FQDN تحت کنترل خود می‌توانید از ساختار سلسله‌مراتبی نام دامنه کمک بگیرید. برای مثال:


https://expected-host.evil-host


• با اعمال رمزنگاری URL بر روی کاراکترها می‌توان رفتار مورد انتظار کد تجزیه‌وتحلیل URL را مختل کرد و آن را به‌اشتباه انداخت. این امر به‌خصوص زمانی مفید خواهد بود که کد اعمال فیلتر و کد ارسال درخواست HTTP به اپلیکیشن پشتیبان، کاراکترهای رمزنگاری‌شده با URL را متفاوت از یکدیگر پردازش کنند. باید توجه داشت که از کاراکترهای رمزنگاری دوگانه نیز می‌توان استفاده کرد. چراکه برخی از سرورها URL ورودی دریافتی خود را به‌صورت بازگشتی رمزگشایی می‌کنند که این امر می‌تواند منجر به ناهماهنگی‌های بیشتر شود.
• با به‌کارگیری ترکیبی روش‌های یادشده می‌توان میزان اثربخشی را افزایش داد و به نتایج مطلوب دست‌یافت.

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

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

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

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


/product/nextProduct?currentProductId=6&path=http://evil-user.net


کاربر را به وب‌سایت خارجی:


http://evil-user.net


تغییر مسیر می‌دهد.

فیلتر URL را می‌توان با استفاده از آسیب‌پذیری تغییر مسیر باز دور زد و از آسیب‌پذیری جعل درخواست در سمت سرور به‌صورت زیر بهره‌برداری کرد:


POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin


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

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

آسیب‌پذیری‌های کورکورانه زمانی ظاهر می‌شوند که بتوان اپلیکیشنی را متقاعد به صدور درخواست پشتیبان HTTP و سپس ارسال به‌سوی URL ارائه‌شده کرد، اما پاسخ درخواست پشتیبان در پاسخ فرانت‌اند اپلیکیشن بازگردانده نمی‌شود.

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

شناسایی نقاط پنهان آسیب‌پذیر در برابر حملات SSRF 

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

وجود URLهای ناقص در درخواست‌های ارائه‌شده به‌سوی سرور

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

URLهای گنجانده‌شده در انواع فرمت‌های دیتا

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

حمله‌ی SSRF با دست‌کاری فیلد هدر Referer واقع در درخواست‌های HTTP

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

منبع: Portswigger