آسیب پذیری Server-side request forgery (SSRF) چیست؟
در این بخش ، ما توضیح خواهیم داد که جعل درخواست سمت سرور چیست ، چند مثال متداول را شرح داده و نحوه پیدا کردن و بهره برداری از انواع آسیب پذیری های SSRF را توضیح خواهیم داد.
SSRF چیست؟
جعل درخواست سمت سرور (SSRF نیز شناخته می شود) یک آسیب پذیری امنیت وب است که به یک مهاجم اجازه می دهد تا برنامه سمت سرور را وادار کند تا درخواست های HTTP را به دامنه دلخواهی که مهاجم انتخاب می کند ، ارائه دهد.
در نمونه های معمولی SSRF ، مهاجم ممکن است باعث شود که سرور مجدداً به خودش یا سایر سرویس های تحت وب در زیرساخت های سازمان یا سیستم های شخص ثالث خارجی ارتباط برقرار کند.
تأثیر حملات SSRF چیست؟
یک حمله موفقیت آمیز SSRF اغلب می تواند منجر به اقدامات غیرمجاز یا دسترسی به داده ها در داخل سازمان شود ، چه در خود برنامه آسیب پذیر و چه در سیستم های دیگر که برنامه می تواند با آنها ارتباط برقرار کند. در برخی شرایط ، آسیب پذیری SSRF ممکن است به یک مهاجم اجازه دهد خودسرانه اجرای دستور را انجام دهد .
یک سو SS استفاده SSRF که باعث اتصال به سیستم های شخص ثالث خارجی می شود ممکن است منجر به حملات سو به جلو شود که به نظر می رسد از سازمان میزبان این برنامه آسیب پذیر نشأت گرفته و منجر به تعهدات قانونی بالقوه و آسیب رساندن به شهرت شود.
حملات مشترک SSRF
حملات SSRF غالباً از روابط اعتماد سو to استفاده می کنند تا حمله را از برنامه آسیب پذیر بالا ببرند و اقدامات غیرمجاز را انجام دهند. این روابط اعتماد ممکن است در رابطه با خود سرور یا در رابطه با سایر سیستم های back-end درون همان سازمان وجود داشته باشد.
حمله SSRF به خود سرور
در حمله SSRF به خود سرور ، مهاجم برنامه را وادار می کند تا از طریق رابط شبکه loopback درخواست HTTP را به سروری که میزبان برنامه است برگرداند. این به طور معمول شامل تهیه URL با نام میزبانی مانند 127.0.0.1(یک آدرس IP ذخیره شده که به آداپتور loopback اشاره می کند) یا localhost(نامی که برای همان آداپتور استفاده می شود).
به عنوان مثال ، یک برنامه خرید را در نظر بگیرید که به کاربر اجازه می دهد موجودی موجود در یک فروشگاه خاص را مشاهده کند. برای ارائه اطلاعات سهام ، برنامه باید از RIE های مختلف REST-back-end ، وابسته به محصول و فروشگاه مورد نظر ، پرس و جو کند. این عملکرد با انتقال URL به نقطه پایانی API مربوط به back-end از طریق درخواست HTTP از قبل انجام می شود. بنابراین هنگامی که یک کاربر وضعیت سهام یک مورد را مشاهده می کند ، مرورگر وی درخواستی مانند این را ارائه می دهد:
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
در اینجا ، سرور محتوای /adminURL را واکشی می کند و آن را به کاربر بازمی گرداند.
البته اکنون ، مهاجم فقط می تواند /adminمستقیماً از URL بازدید کند . اما عملکرد اداری معمولاً فقط برای کاربران معتبر معتبر قابل دسترسی است. بنابراین مهاجمی که به سادگی از URL بازدید می کند ، مورد علاقه ای را مشاهده نخواهد کرد. با این حال ، هنگامی که درخواست از /adminURL توسط خود ماشین محلی ارائه می شود ، کنترل های دسترسی عادی کنار گذاشته می شوند. این برنامه دسترسی کامل به قابلیتهای اجرایی را اعطا می کند ، زیرا به نظر می رسد این درخواست از یک مکان معتبر سرچشمه گرفته است.
چرا برنامه ها اینگونه رفتار می کنند و به درخواستهایی که از دستگاه محلی می آید ، ضمنی اعتماد دارند؟ این می تواند به دلایل مختلف بوجود آید:
- کنترل دسترسی چک ممکن است در قطعات متفاوت است که در مقابل سرور نرم افزار نشسته اجرا شده است. هنگامی که اتصال به خود سرور برقرار می شود ، بررسی انجام نمی شود.
- برای اهداف بازیابی فاجعه ، این برنامه ممکن است بدون ورود به سیستم ، به هر کاربری که از دستگاه محلی می آید دسترسی اداری را داشته باشد. این راهی را برای یک مدیر فراهم می کند تا در صورت از دست دادن اعتبار خود ، سیستم را بازیابی کند. در اینجا فرض این است که فقط یک کاربر کاملاً مطمئن می تواند مستقیماً از سرور خود استفاده کند.
- رابط کاربری اداری ممکن است با شماره پورت متفاوتی از برنامه اصلی در حال گوش دادن باشد ، بنابراین ممکن است مستقیماً توسط کاربران قابل دسترسی نباشد.
این نوع روابط اعتماد ، جایی که درخواست های ناشی از ماشین محلی به طور متفاوتی از درخواست های معمولی رسیدگی می شود ، اغلب باعث می شود SSRF به یک آسیب پذیری مهم تبدیل شود.
حملات SSRF علیه سایر سیستم های back-end
نوع دیگری از رابطه اعتماد که غالباً با جعل درخواست سمت سرور ایجاد می شود ، جایی است که سرور برنامه قادر به تعامل با سایر سیستم های back-end باشد که به طور مستقیم توسط کاربران قابل دسترسی نیستند. این سیستم ها غالباً آدرس های IP خصوصی غیرقابل مسیریابی دارند. از آنجا که سیستم های back-end به طور معمول توسط توپولوژی شبکه محافظت می شوند ، اغلب وضعیت امنیتی ضعیف تری دارند. در بسیاری از موارد ، سیستم های داخلی داخلی دارای قابلیت های حساسی هستند که بدون احراز هویت توسط کسی که قادر به تعامل با سیستم است ، می توان به آن دسترسی پیدا کرد.
در مثال قبلی ، فرض کنید یک رابط مدیریتی در URL انتهایی وجود دارد https://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