در این مقاله توضیح می‌دهیم حمله‌ی SSRF (کوتاه‌شده‌ی Sever-Side Request Forgery) یا «تولید ریکوئست‌های سمت سرور» چیست؟ چند نمونهی ساده از آن را تشریح می‌کنیم، و توضیح می‌دهیم چطور می‌توانید انواع آسیب‌پذیری‌های SSRF را شناسایی و اکسپلویت کنید.
- SSRF چیست؟
- حملات SSRF چه عواقبی دارند؟
- انواع رایج حملات SSRF
- حملات SSRF علیه خود سرور
- حملات SSRF علیه سیستم‌های بک‌اند دیگر
- دورزدن راهکارهای دفاع در برابر SSRF
- دورزدن فیلترهای SSRF با اکسپلویت Open Redirection
- آسیب‌پذیری Blind SSRF
- میزان تاثیرگذاری آسیب‌پذیری Blind SSRF چقدر است؟
- نحوه یافتن و اکسپلویت آسیب‌پذیری‌های Blind SSRF
- یافتن سطح حمله‌ی مخفی آسیب‌پذیری‌های SSRF
SSRF چیست؟
تولید ریکوئست‌های سمت سرور یا همان SSRF، یک آسیب‌پذیری وب است که مهاجم با استفاده از آن می‌تواند کاری کند که اپلیکیشن سمت سرور، به دامنه‌ی دلخواه او ریکوئست‌های HTTP بفرستد.
در نمونه‌های رایج SSRF، مهاجم ممکن است باعث شود که سرور به خودش (به صورت لوپ‌بک)، با دیگر سرویس‌های وب داخل زیرساخت سازمان یا سیستم‌های خارجی متفرقه، اتصال برقرار کند.
حملات SSRF چه عواقبی دارند؟
یک حمله SSRF موفق معمولا می‌تواند منجر به انجام اقدامات غیرمجاز یا دسترسی بدون مجوز به داده‌های داخل یک سازمان شود. این عواقب ممکن است متوجه خود اپلیکیشن آسیب‌پذیر باشند، یا ممکن است برای سیستم‌های بک‌اندی اتفاق بیافتند که اپلیکیشن با آن‌ها در ارتباط است. بعضی مواقع، آسیب‌پذیری SSRF ممکن است به مهاجم اجازه دهد که حملات ACE (اجرای دستورات دلخواه یا Arbitrary Code Execution) را انجام دهد.
یک اکسپلویت SSRF که باعث برقراری اتصال به یک سیستم متفرقه‌ی خارجی شود، ممکن است حملات مخربی را در پی داشته باشد که در ظاهر مبدأ آن‌ها سازمانی است که اپلیکیشن آسیب‌پذیر را میزبانی می‌کرده، و به همین جهت ممکن است باعث به‌وجودآمدن مشکلات حقوقی و آسیب‌رسیدن به وجهه‌ی سازمان شوند.
«مطلب مشابه»
انواع رایج حملات SSRF
حملات SSRF معمولا اعتمادی که بین سیستم‌های مختلف وجود دارد را اکسپلویت می‌کنند تا بتوانند گستره‌ی حمله را از اپلیکیشن آسیب‌پذیر فراتر ببرند و اقدامات غیرمجاز مد نظر خود را انجام دهند. این اعتماد ممکن است در همان سروری وجود داشته باشد که اپلیکیشن را میزبانی می‌کند، یا ممکن است برای سیستم‌های بک‌اند دیگر در همان سازمان نیز برقرار باشد؛ به همین جهت می‌توان حملات SSRF را به دو دسته‌ی اصلی تقسیم کرد: حملاتی که علیه خود سرور انجام می‌شوند، و حملاتی که علیه سیستم‌های بک‌اند دیگر در سازمان انجام می‌شوند.
حملات SSRF علیه خود سرور
در حملات SSRF که علیه خود سرور انجام می‌شوند، مهاجم کاری می‌کند که اپلیکیشن با استفاده از رابط شبکه‌ی لوپ‌بک (loopback) خود، یک ریکوئست HTTP به سروری بفرستد؛ که آن را میزبانی می‌کند. برای این کار معمولا لازم است یک URL و یک host name مانند 127.0.0.1 (یک آدرس IP رزروشده که متعلق به آداپتور لوپ‌بک است) یا localhost (نامی که معمولا برای همین آداپتور استفاده می‌شود) وجود داشته باشد.
برای مثال، یک اپلیکیشن خرید را فرض کنید که به کاربران اجازه می‌دهد موجودی یک محصول خاص در یک فروشگاه را بررسی کنند. اپلیکیشن برای تهیه‌ی اطلاعات موجودی محصول، بسته به محصول و فروشگاه، باید به REST APIهای بک‌اند مختلفی کوئری بزند. این عملکرد به این صورت پیاده شده که URL از طریق یک ریکوئست فرانت‌اند HTTP به اندپوینت بک‌اند 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 به خود سرور قرار دهد. برای مثال:
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://localhost/admin
سرور با دریافت این ریکوئست، محتویات آدرس /admin را به کاربر برمی‌گرداند.
البته مشخص است که مهاجم می‌تواند خودش مستقیما به آدرس /admin سر بزند؛ اما عملکردهای مخصوص ادمین معمولا تنها برای کاربرانی در دسترس هستند که احراز هویت مناسب را انجام داده باشند. بنابراین وقتی مهاجم مستقیما به این URL سر بزند، چیز مهمی دستگیرش نمی‌شود. اما وقتی ریکوئست به آدرس /admin مستقیما از سوی یک ماشین محلی ارسال شده باشد، کنترل‌های دسترسی معمولی دیگر اعمال نمی‌شوند (Bypass می‌شوند). اپلیکیشن در پاسخ به چنین ریکوئستی، دسترسی کامل به عملکردهای ادمین را اعطا می‌کند؛ چون به نظر می‌رسد که ریکوئست از محل مورد اعتمادی ارسال شده است.
اما چرا اپلیکیشن‌ها این‌گونه عمل می‌کنند و به طور غیرمستقیم به ریکوئست‌هایی که از ماشین محلی ارسال می‌شوند، اعتماد می‌کنند؟ این مساله ممکن است دلایل مختلفی داشته باشد:
- ممکن است راهکار کنترل دسترسی در بخش جداگانه‌ای پیاده‌سازی شده باشد که جلوی سرور اپلیکیشن قرار دارد. وقتی یک اتصال از سرور به خودش انجام می‌شود، توسط این راهکار بررسی نمی‌شود.
- اپلیکیشن ممکن است برای تسهیل بازیابی از حادثه، به تمام کاربرانی که از ماشین‌های محلی آمده‌اند، بدون نیاز به لاگین اجازه‌ی دسترسی سطح ادمین را بدهد. این گونه اگر ادمین اطلاعات ورود خود را فراموش کرد، راهی برای بازیابی سیستم دارد. در این‌جا فرض بر این است که فقط کاربری مستقیما از خود سرور ریکوئست ارسال می‌کند که کاملا مورد اعتماد است.
- پورتی که رابط شبکه‌ی ادمین به آن گوش می‌کند ممکن است با اپلیکیشن اصلی متفاوت باشد، و به همین علت ممکن است به‌صورت مستقیم توسط کاربران قابل دسترسی نباشد.
عمدتاً این اعتمادها هستند که SSRF را تبدیل به یک آسیب‌پذیری حیاتی می‌کنند؛ یعنی زمانی که ریکوئست‌های ارسال‌شده از ماشین محلی نسبت به ریکوئست‌های معمولی به روش متفاوتی پردازش می‌شوند.
حملات SSRF علیه سیستم‌های بک‌اند دیگر
نوع دیگری از این اعتمادها که معمولا زمینه‌ی حملات SSRF را به وجود می‌آورند، مربوط به مواقعی است که سرور اپلیکیشن می‌تواند با سیستم‌های بک‌اند دیگری تعامل کند که به‌طور مستقیم در دسترس کاربران نیستند. این سیستم‌ها معمولا آدرس‌های IP خصوصی non-routable دارند (یعنی از خارج شبکه نمی‌توان با آن‌ها ارتباط برقرار کرد). از آن‌جایی که سیستم‌های بک‌اند معمولا به صورت مستقیم توسط توپولوژی شبکه محافظت می‌شوند، عمدتاً وضعیت امنیتی ضعیف‌تری دارند. در بسیاری از موارد، سیستم‌های بک‌اند داخلی عملکردهای حساسی را انجام می‌دهند که هرکس بتواند با این سیستم‌ها تعامل کند، بدون احراز هویت به آن‌ها دسترسی دارد.
در مثال قبلی، فرض کنید یک رابط ادمین در آدرس URL بک‌اند 192.168.0.68/admin قرار دارد. در این صورت یک مهاجم می‌تواند آسیب‌پذیری SSRF را اکسپلویت کند و با ارسال ریکوئست زیر، به این رابط ادمین دسترسی پیدا کند:
POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
stockApi=http://192.168.0.68/admin
دورزدن راهکارهای دفاع در برابر SSRF
اپلیکیشن‌های زیادی با وجود این که آسیب‌پذیری SSRF دارند، راهکارهایی دفاعی در کنار آن قرار داده‌اند تا از اکسپلویت آن جلوگیری کنند. البته، خیلی اوقات می‌توان این راهکارها را دور زد.
SSRF با فیلترهای ورودی مبتنی بر لیست سیاه
برخی اپلیکیشن‌ها ورودی‌های را که حاوی host name هایی مانند 127.0.0.1 و localhost، یا URL های حساس مانند /admin باشند، بلاک می‌کنند. در این مواقع، معمولا می‌توانید با تکنیک‌های متنوعی، این فیلترها را دور بزنید:
- استفاده از یک نمادگذاری متفاوت برای واردکردن آدرس آی‌پی 0.0.1؛ مانند 2130706433، 017700000001 یا 127.1
- ثبت‌کردن یک نام دامنه برای خودتان که آی‌پی آن 0.0.1 باشد. برای این منظور می‌توانید از آدرس spoofed.burpcollaborator.net هم استفاده کنید.
- مبهم‌سازی استرینگ‌های بلاک‌شده از طریق انکودینگ URL یا بزرگ و کوچک کردن حروف (case varitation)
SSRF با فیلترهای ورودی مبتنی بر لیست سفید
بعضی اپلیکیشن‌ها یک لیست سفید از مقادیر مجاز دارند و تنها ورودی‌هایی را قبول می‌کنند که با حداقل یکی از این مقادیر مطابقت داشته باشند، با یکی از این مقادیر شروع شده باشند یا حاوی یکی از این مقادیر باشند. بعضی اوقات می‌توانید با اکسپلویت شکاف‌های موجود در فرایند تجزیه URL (یا URL Parsing)، این فیلتر را دور بزنید.
URL در تعریف خود قابلیت‌هایی دارد که ممکن است هنگام پیاده‌سازی پارسرهای ad hoc و اعتبارسنجی URL، به آن‌ها توجه نشده باشد (در مثال‌ها به جای آدرس هاست مورد انتظار expected-host و به جای آدرس هاست غیرمجاز evil-host قرار داده شده است):
- شما می‌توانید با استفاده از کاراکتر @، در دل URL و قبل از نام هاست، اطلاعات ورود را قرار دهید. برای مثال:
https://expected-host@evil-host
- شما می‌توانید از کاراکتر # برای نشان‌دادن یک URL Fragment استفاده کنید. برای مثال:
https://evil-host#expected-host
- شما می‌توانید از سلسله مراتب نام‌گذاری و ترتیب تبدیل نام دامنه به IP در سیستم DNS استفاده کنید و ورودی مورد نظر خود را در نام دامنه‌ای بگذارید که از نظر فیلتر ورودی کاملا مجاز است ولی در کنترل شماست. برای مثال:
https://expected-host.evil-host
- شما می‌توانید کاراکترهای URL را انکود کنید تا کدی که وظیفه‌ی تجزیه‌ی URL را دارد گیج شود. این کار به ویژه در مواقعی مفید است که نحوه‌ی رفتار با کاراکترهای انکودشده در URL در کدی که فیلتر با آن پیاده‌سازی شده و کدی که ریکوئست‌های HTTP بک‌اند را انجام می‌دهد، متفاوت باشد.
- شما می‌توانید ترکیبی از این تکنیک‌ها را انجام دهید.
دورزدن فیلترهای SSRF با اکسپلویت Open Redirection
بعضی اوقات می‌توان با اکسپلویت یک آسیب‌پذیری Open Redirection راهکارهای دفاعی مبتنی بر فیلتر را دور زد. پیش از آن باید ببینیم آسیب‌پذیری Open Redirect چیست؟
«مطلب مشابه»
آسیب‌پذیری Open Redirection چیست؟
آسیب‌پذیری‌های Open Redirection زمانی به وجود می‌آیند که یک وب‌اپلیکیشن از داده‌هایی که در کنترل کاربر هستند، به طور مستقیم برای هدایت یا ریدایرکشن غیرایمن به یک آدرس خاص استفاده می‌کند. یک مهاجم می‌تواند یک URL داخل اپلیکیشن بسازد، و آن را به‌گونه‌ای طراحی کند که باعث هدایت‌شدن اپلیکیشن به یک دامنه‌ی خارجی دلخواه مهاجم شود. با بهره‌گیری از این شکاف امنیتی، می‌توان علیه کاربران آن اپلیکیشن حملات فیشینگ انجام داد. مهاجم در این نوع حمله می‌تواند از URL اصلی اپلیکیشن استفاده کند و دامنه‌ی درست و معتبر را هدف قرار دهد که یک گواهینامه SSL معتبر هم دارد (البته اگر اپلیکیشن هدف، از SSL استفاده کرده باشد). همین باعث می‌شود حمله‌ی فیشینگ باورپذیرتر شود، چون اکثر کاربران حتی اگر معتبربودن دامنه و اعتبار SSL را بررسی کنند، متوجه ریدایرکت‌شدن به یک دامنه‌ی متفاوت نمی‌شوند.
اکسپلویت Open Redirection و دور زدن فیلترهای SSRF
در مثال قبلی حمله SSRF، فرض کنید URL ثبت‌شده توسط کاربر با سخت‌گیری تمام اعتبارسنجی می‌شود تا از اکسپلویت SSRF جلوگیری شود. با این وجود، اپلیکیشنی که URLهای مربوط به آن مجاز هستند، حاوی یک آسیب‌پذیری Open Redirection است. با فرض این که API مورد استفاده برای ارسال ریکوئست‌های HTTP بک‌اند از ریدایرکت پشتیبانی می‌کند، شما می‌توانید یک URL بسازید که از فیلتر عبور می‌کند و باعث می‌شود یک ریکوئست ریدایرکت‌شده به هدف بک‌اند مطلوب شما زده شود.
برای مثال، فرض کنید اپلیکیشن یک آسیب‌پذیری open redirection دارد که در آن URL زیر:
/product/nextProduct?currentProductId=6&path=http://evil-user.net
ریدایرکت زیر را برمی‌گرداند:
http://evil-user.net
شما می‌توانید از آسیب‌پذیری open redirection برای دورزدن فیلتر URL استتفاده کنید، و آسیب‌پذیری SSRF را به این شکل اکسپلویت کنید:
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 داده‌شده یک ریکوئست ارسال می‌کند، که باعث انجام یک open redirection می‌شود. اپلیکیشن ریدایرکت را دنبال می‌کند، و به URL داخلی که مهاجم مشخص کرده، یک ریکوئست ارسال می‌کند.
از بین بردن آسیب‌پذیری Open Redirection
در صورت امکان، اپلیکیشن باید از به‌کاربردن داده‌های تحت کنترل کاربر در ریدایرکشن به اهداف مختلف خودداری کند. در موارد زیادی، به دو روش می‌توان از این رفتار جلوگیری کرد:
- به طور کلی امکان ریدایرکت را از اپلیکیشن حذف کنید، و لینک‌هایی را که به اپلیکیشن منتهی می‌شوند، با لینک‌های مستقیم به URLهای هدف مورد نظر جایگزین کنید.
- در سمت سرور یک لیست از تمام URLهایی که ریدایرکشن به آن‌ها مجاز است نگه دارید. به جای این که URL هدف را به صورت یک پارامتر به ریدایرکتور ارسال کنید، به آن یک ایندکس از این لیست (یعنی همان شماره‌ی URL مورد نظر در لیست) ارسال کنید.
اگر به این نتیجه رسیدید که امکان عدم استفاده از داده‌های تحت کنترل کاربر در تعیین هدف ریدایرکشن وجود ندارد، باید با به‌کارگیری یکی از روش‌های زیر، خطر حملات ریدایرکشن را به حداقل برسانید:
- اپلیکیشن باید در تمام ریدایرکت‌های خود فقط و فقط از URLهای نسبی (relative) استفاده کند، و تابع ریدایرکشن باید به طور دقیق بررسی کند که URL دریافت‌شده حتما یک URL نسبی باشد.
- اپلیکیشن فقط باید در تمام ریدایرکت‌های خود از URLهایی استفاده کند که مبدأ آن‌ها web root باشد، و تابع ریدایرکشن هم باید بررسی کند که URL دریافت‌شده با کاراکتر اسلش (کاراکتر « / ») شروع شده باشد، و پیش از انجام ریدایرکشن، http://yourdomainname.com را به ابتدای URL بچسباند (به جای com نام دامنه شما قرار می‌گیرد).
- در صورتی که اپلیکیشن از URLهای مطلق (absolute) برای تمام ریدایرکشن‌های خود استفاده کند، تابع ریدایرکشن قبل از انجام ریدایرکت باید بررسی کند که تمام URLهای واردشده توسط کاربر با http://yourdomainname.com/ شروع شده باشند (به جای com نام دامنه شما قرار می‌گیرد).
آسیب‌پذیری Blind SSRF
آسیب‌پذیری‌های Blind SSRF یا SSRF کور، زمانی به وجود می‌آیند که می‌توانیم کاری کنیم که اپلیکیشن یک ریکوئست HTTP بک‌اند به یک URL داده‌شده ارسال کند، ولی پاسخ ریکوئست بک‌اند در پاسخ فرانت‌اند اپلیکیشن به کاربر برگردانده نمی‌شود.
معمولا اکسپلویت آسیب‌پذیری‌های Blind SSRF سخت‌تر است، ولی همین آسیب‌پذیری‌ها هم گاهی اوقات ممکن است منجر به اجرای کد از راه دور روی سرور یا دیگر تاسیسات بک‌اند شود.
میزان تاثیرگذاری آسیب‌پذیری Blind SSRF چقدر است؟
معمولا دست مهاجم در اکسپلویت آسیب‌پذیری‌های SSRF کور به اندازه آسیب‌پذیری‌های SSRF معمولی باز نیست؛ زیرا آسیب‌پذیری‌های کور ذاتاً یک‌طرفه هستند. نمی‌توان به سادگی این آسیب‌پذیری‌ها را اکسپلویت کرد و داده‌های حساس را مستقیماً از سیستم‌های بک‌اند به دست آورد، اگرچه در بعضی موارد می‌توان با اکسپلویت این آسیب‌پذیری‌ها، یک حمله RCE (اجرای کد از راه دور) کامل انجام داد.
نحوه یافتن و اکسپلویت آسیب‌پذیری‌های Blind SSRF
مطمئن‌ترین راه برای یافتن آسیب‌پذیری‌های SSRF کور، استفاده از تکنیک‌های out-of-band یا OAST است. در این تکنیک‌ها باید کاری کنید که یک ریکوئست HTTP به سیستمی خارجی زده شود که در کنترل شماست، و سپس تعاملات انجام شده با آن سیستم را مانیتور کنید.
آسان‌ترین و موثرترین راه برای استفاده از تکنیک‌های out-of-band، استفاده از Burp Collaborator است. شما می‌توانید با استفاده از کلاینت Burp Collaborator نام دامنه‌های منحصربه‌فرد تولید کنید، و این نام‌های دامنه را درون پی‌لودهای خود به اپلیکیشن بفرستید، و سپس تعامل‌های صورت‌گرفته با این نام‌های دامنه را مانیتور کنید. اگر مشاهده کردید که ریکوئست HTTP مورد نظر شما از اپلیکیشن دریافت شد، متوجه می‌شوید که اپلیکیشن آسیب پذیری SSRF دارد.
نکته: خیلی اوقات وقتی دارید وجود آسیب‌پذیری SSRF را تست می‌کنید، مشاهده می‌کنید که به دامنه‌ی تولیدشده توسط Collaborator یک ریکوئست DNS Lookup زده می‌شود، ولی بعد از آن هیچ ریکوئست HTTP به آن دامنه ارسال نمی‌شود. این اتفاق معمولا زمانی رخ می‌دهد که اپلیکیشن سعی کرده یک ریکوئست HTTP به دامنه ارسال کند، که پیش از آن لازم بوده یک ریکوئست DNS Lookup ارسال کند، ولی خود ریکوئست HTTP توسط یک مکانیزم فیلترینگ در سطح شبکه (مثل فایروال) بلاک شده است. این مساله‌ی نسبتاً رایجی است که به خاطر نیاز به ترافیک خروجی DNS برای انجام کارهای مختلف، زیرساخت اجازه‌ی خروج ترافیک DNS را می‌دهد، ولی اتصالات HTTP به مقاصد غیرمنتظره بلاک می‌شود.
این که صرفاً متوجه شوید یک آسیب‌پذیری SSRF کور می‌تواند باعث ارسال ریکوئست‌های HTTP به صورت out-of-band شود، به خودی‌خود امکان اکسپلویت را به وجود نمی‌آورد. از آن‌جایی که نمی‌توانید پاسخ ارسال‌شده در جواب ریکوئست بک‌اند را ببینید، نمی‌توانید از این رفتار برای مشاهده‌ی محتوای موجود روی سیستم‌هایی استفاده کنید که سرور اپلیکیشن امکان دسترسی به آن‌ها را دارد. با این وجود، از این آسیب‌پذیری می‌توان برای جستجو به دنبال آسیب‌پذیری‌های دیگر روی خود سرور یا بقیه‌ی سیستم‌های بک‌اند استفاده کرد. شما می‌توانید کورکورانه به تمام آدرس‌های IP داخلی، پیلودهایی ارسال کنید که برای شناسایی آسیب‌پذیری‌های رایج و شناخته‌شده طراحی شده‌اند. اگر داخل این پی‌لودها هم از تکنیک‌های out-of-band استفاده کرده باشید، ممکن است بتوانید یک آسیب‌پذیری حیاتی در یک سرور داخلی پچ‌نشده پیدا کنید.
یک راه دیگر برای اکسپلویت آسیب‌پذیری‌های SSRF کور، این است که کاری کنیم که اپلیکیشن به سیستمی متصل شود که تحت کنترل ماست، و به کلاینت HTTP که اتصال را ایجاد کرده است، پاسخ‌های مخرب ارسال کنیم. اگر بتوانید یک آسیب‌پذیری سمت کلاینت جدی را در سرویس HTTP سرور بیابید، ممکن است بتوانید یک حمله RCE (اجرای کد از راه دور) داخل زیرساخت اپلیکیشن انجام دهید.
یافتن سطح حمله‌ی مخفی آسیب‌پذیری‌های SSRF
پیداکردن بسیاری از آسیب‌پذیری‌های SSRF نسبتاً راحت است، چون در صورت وجود این آسیب‌پذیری، ترافیک معمولی اپلیکیشن شامل پارامترهایی است که حاوی URLهای کامل هستند. یافتن نمونه‌های دیگر SSRF سخت‌تر است.
URLهای ناقص در ریکوئست‌ها
بعضی مواقع، اپلیکیشن فقط نام هاست یا بخشی از مسیر URL را داخل پارامترهای ریکوئست قرار می‌دهد. سپس مقدار ثبت‌شده در سمت سرور استفاده شده و URL کامل ریکوئست‌شده، ساخته می‌شود. اگر این مقدار به طور خودکار به عنوان یک hostname یا مسیر URL شناخته شود، در این صورت سطح حمله‌ی احتمالی مشخص است. با این وجود، در چنین مواردی، نمی‌توان مثل یک آسیب‌پذیری SSRF تمام‌عیار چنین رفتاری را اکسپلویت کرد، چون مهاجم کل URL ریکوئست‌شده را کنترل نمی‌کند.
URLهای قرارگرفته در قالب‌های داده مختلف
اپلیکیشن‌ها داده‌ها را در قالب‌های متفاوتی انتقال می‌دهند. بعضی از این قالب‌ها به شما اجازه می‌دهند در میان داده‌ها URLهایی را قرار دهید و توسط پارسر داده‌ی آن قالب خاص، به آن URLها ریکوئست داده می‌شود. یک مثال معروف از این نوع قالب‌ها، قالب XML است، که به طور گسترده توسط وب‌اپلیکیشن‌ها برای انتقال داده‌های ساختارمند از کلاینت به سرور استفاده می‌شود. وقتی یک اپلیکیشن داده را در قالب XML قبول کرده و آن را parse می‌کند، ممکن است نسبت به XXE Injection آسیب‌پذیر باشد، و به همین ترتیب ممکن است نسبت به SSRF از طریق XXE نیز آسیب‌پذیر باشد. برای مطالعه بیشتر درباره آسیب‌پذیری‌های XXE، به مقاله حملات تزریق XXE مراجعه کنید.
SSRF از طریق هدر Referer
بعضی از اپلیکیشن‌ها برای ردیابی بازدیدکنندگان خود از نرم‌افزارهای تحلیلی سمت سرور استفاده می‌کنند. این نوع نرم‌افزارها معمولا از هدر Referer در ریکوئست‌ها لاگ می‌گیرند، زیرا این هدر برای ردیابی لینک‌های ورودی به کار می‌آید. این کار معمولا با این هدف انجام می‌شود که محتوای سایت‌هایی که کاربران از آن‌جا به اپلیکیشن ارجاع داده شده‌اند (یا refer شده‌اند)، از جمله anchor text (متن انکر، متنی که به جای لینک نمایش داده می‌شود) بررسی شود. به همین خاطر، هدر Referer معمولا یک سطح حمله‌ی احتمالی برای آسیب‌پذیری‌های SSRF است.
