Server-Side Request Forgery (SSRF) یک آسیبپذیری امنیتی وب است که به مهاجم اجازه میدهد تا برنامه سمت سرور را وادار کند تا درخواستهای HTTP را به دامنه دلخواه خود به انتخاب مهاجم ارسال کند.
در یک حمله معمولی SSRF، مهاجم ممکن است باعث شود سرور به سرویسهای داخلی در زیرساخت سازمان متصل شود. در موارد دیگر، آنها ممکن است بتوانند سرور را مجبور به اتصال به سیستم های خارجی دلخواه کنند
یک حمله موفقیت آمیز SSRF اغلب می تواند منجر به اقدامات غیرمجاز یا دسترسی به داده ها در داخل سازمان شود، چه در خود برنامه آسیب پذیر یا در سایر سیستم های پشتیبان که برنامه می تواند با آنها ارتباط برقرار کند. در برخی شرایط، آسیبپذیری SSRF ممکن است به مهاجم اجازه اجرای دستور دلخواه را بدهد.
در یک حمله SSRF علیه خود سرور، مهاجم برنامه را وادار می کند تا یک درخواست HTTP را از طریق رابط شبکه Loopback خود به سرور میزبان برنامه بازگرداند. این معمولاً شامل ارائه یک URL با نام میزبان مانند 127.0.0.1 (یک آدرس IP رزرو شده که به آداپتور Loopback اشاره می کند) یا localhost (نامی که معمولاً برای همان آداپتور استفاده می شود) است.
به عنوان مثال، یک برنامه کاربردی خرید را در نظر بگیرید که به کاربر امکان می دهد ببیند آیا یک کالا در یک فروشگاه خاص موجود است یا خیر. برای ارائه اطلاعات موجودی، برنامه باید بسته به محصول و فروشگاه مورد نظر از API های پشتیبان REST مختلف پرس و جو کند. این تابع با ارسال 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
در اینجا سرور محتوای URL /admin را دریافت کرده و آن را به کاربر باز می گرداند.
در این نوع حملات، برنامه قادر به تعامل با سایر سیستم های پشتیبان است که مستقیماً توسط کاربران قابل دسترسی نیستند. این سیستم ها اغلب دارای آدرس های IP خصوصی غیر قابل مسیریابی هستند. از آنجایی که سیستمهای بکاند معمولاً توسط توپولوژی شبکه محافظت میشوند، اغلب وضعیت امنیتی ضعیفتری دارند. در بسیاری از موارد، سیستمهای بکاند داخلی دارای قابلیتهای حساسی هستند که هر کسی که قادر به تعامل با سیستمها باشد
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://192.168.0.68/admin
برخی از برنامه ها ورودی های حاوی نام میزبان مانند 127.0.0.1 و localhost یا URL های حساس مانند /admin را مسدود می کنند. در این شرایط، اغلب می توانید با استفاده از تکنیک های مختلف فیلتر را دور بزنید:
1 با استفاده از نمایش IP جایگزین 127.0.0.1، مانند 2130706433، 017700000001، یا 127.1.
2 مبهم سازی رشته های مسدود شده با استفاده از رمزگذاری URL یا تغییر حروف کوچک.
برخی از برنامهها فقط ورودیهایی را مجاز میکنند که با لیست سفید مقادیر مجاز مطابقت داشته باشد. در این شرایط، گاهی اوقات میتوانید با استفاده از ناهماهنگیها در تجزیه URL، فیلتر را دور بزنید.
1 میتوانید با استفاده از کاراکتر @، اعتبارنامهها را قبل از نام میزبان در URL جاسازی کنید.
https://expected-host@evil-host
2 می توانید از کاراکتر # برای نشان دادن یک قطعه URL استفاده کنید.
https://evil-host#expected-host
3 میتوانید از سلسلهمراتب نامگذاری DNS برای قرار دادن ورودی موردنیاز در یک نام DNS کاملاً واجد شرایط که کنترل میکنید، استفاده کنید.
https://expected-host.evil-host
4 می توانید برای اشتباه گرفتن کد تجزیه URL، کاراکترهای URL را رمزگذاری کنید. این به ویژه در صورتی مفید است که کدی که فیلتر را پیادهسازی میکند، کاراکترهای کدگذاری شده با URL را متفاوت از کدی که درخواست HTTP پشتیبان را انجام میدهد، مدیریت میکند.
آسیبپذیریهای کور SSRF زمانی به وجود میآیند که میتوان برنامهای را وادار کرد که یک درخواست HTTP پشتیبان را به URL ارائهشده صادر کند، اما پاسخ درخواست بکاند در پاسخ جلویی برنامه برگردانده نمیشود.
بهره برداری از SSRF کور معمولا سخت تر است، اما گاهی اوقات می تواند منجر به اجرای کامل کد از راه دور بر روی سرور یا سایر اجزای پشتیبان شود.
یک رویکرد محکم برای اجتناب از SSRF این است که آدرسهای IP یا نامهای DNS را که برنامه شما نیاز به دسترسی به آنها دارد در لیست سفید قرار دهید. تنها در صورتی که رویکرد لیست سفید مناسب نیست، باید از لیست سیاه استفاده کنید. ضروری است که ورودی کاربر را به طور مؤثر تأیید کنید.
برای جلوگیری از رسیدن اطلاعات پاسخ به هکر، باید مطمئن شوید که پاسخ دریافت شده با آنچه پیش بینی شده است مطابقت دارد. به هیچ وجه نباید بدنه پاسخ خام دریافت شده از درخواست آغاز شده توسط سرور به مشتری منتقل شود.
منبع: وب سایت portswigger
در این قسمت، به پرسشهای تخصصی شما دربارهی محتوای مقاله پاسخ داده نمیشود. سوالات خود را اینجا بپرسید.