اصول امنیت وب: توضیح SSRF، CSRF و CORS
در دنیای مدرن وب، امنیت صرفاً یک ویژگی نیست، بلکه یک پایه و اساس است. با متصلتر شدن اپلیکیشنها به یکدیگر، درک جزئیات نحوه مدیریت درخواستها در دامنهها و سرورهای مختلف برای هر توسعهدهندهای حیاتی است.
امروز، ما به بررسی سه مفهوم حیاتی میپردازیم که هر توسعهدهنده وب باید بر آنها مسلط باشد: SSRF، CSRF و CORS. اگرچه ممکن است این نامها پیچیده به نظر برسند، اما آنها خط مقدم امنیت اپلیکیشنهای وب هستند.
۱. SSRF (جعل درخواست سمت سرور)
SSRF یک آسیبپذیری است که در آن مهاجم میتواند یک اپلیکیشن سمت سرور را مجبور کند تا درخواستهای HTTP را به یک دامنه دلخواه که توسط مهاجم انتخاب شده است، ارسال کند.
نحوه عملکرد
یک اپلیکیشن وب را تصور کنید که یک URL را به عنوان ورودی میگیرد (مثلاً برای دریافت عکس پروفایل یا پیشنمایش یک لینک) و سپس درخواستی را از طرف سرور به آن URL ارسال میکند. اگر اپلیکیشن این URL را به درستی اعتبارسنجی نکند، مهاجم میتواند یک آدرس IP داخلی یا آدرس لوپبک (127.0.0.1) را وارد کند.
سرور که به عنوان یک پروکسی عمل میکند، ممکن است دادههای حساسی را از سرویسهای داخلی که در اینترنت عمومی در دسترس نیستند، دریافت کند، مانند:
- متادیتای ابری: دسترسی به
169.254.169.254در AWS/GCP برای بازیابی اعتبارنامههای IAM. - پنلهای مدیریتی داخلی: دسترسی به ابزارهای داخلی مانند Jenkins یا داشبوردهای Kubernetes.
- اسکن پورتها: شناسایی سایر سرویسهای در حال اجرا در شبکه داخلی.
پیشگیری
- لیست سفید (Allowlisting): فقط اجازه ارسال درخواست به لیستی از دامنههای قابل اعتماد از پیش تعریف شده را بدهید.
- اعتبارسنجی ورودی: اطمینان حاصل کنید که URL از پروتکلهای مجاز (مثلاً فقط
https://) استفاده میکند و به محدودههای IP داخلی اشاره نمیکند. - جداسازی شبکه: اطمینان حاصل کنید که وبسرور دسترسی محدودی به منابع داخلی دارد.
۲. CSRF (جعل درخواست بینسایتی)
CSRF حملهای است که مرورگر قربانی را فریب میدهد تا عملی ناخواسته را در وبسایت دیگری که قربانی در آن لاگین است، انجام دهد.
نحوه عملکرد
این حمله از این واقعیت سوءاستفاده میکند که مرورگرها به طور خودکار اعتبارنامهها - مانند کوکیهای نشست (session) - را با هر درخواست به یک دامنه ارسال میکنند.
- کاربر وارد
bank.comمیشود. - کاربر یک سایت مخرب
evil.comرا در تب دیگری باز میکند. - سایت
evil.comحاوی یک فرم مخفی است که یک درخواستPOSTبه آدرسbank.com/transfer?amount=1000&to=attackerارسال میکند. - مرورگر درخواست را همراه با کوکی نشست کاربر در
bank.comارسال میکند. - سایت
bank.comیک نشست معتبر را میبیند و عملیات انتقال را انجام میدهد.
پیشگیری
- توکنهای Anti-CSRF: یک توکن منحصربهفرد، مخفی و غیرقابل پیشبینی را در هر درخواستی که وضعیت را تغییر میدهد، بگنجانید. سرور قبل از پردازش، این توکن را تایید میکند.
- کوکیهای SameSite: ویژگی
SameSiteرا در کوکیها رویStrictیاLaxتنظیم کنید تا از ارسال آنها در درخواستهای بینسایتی جلوگیری شود. - هدرهای سفارشی: برای درخواستهای AJAX، یک هدر سفارشی (مانند
X-Requested-With) بخواهید که توسط یک فرم استاندارد HTML قابل تنظیم نباشد.
۳. CORS (اشتراکگذاری منابع بینمنشأیی)
برخلاف SSRF و CSRF، مفهوم CORS به خودی خود یک آسیبپذیری نیست، بلکه یک مکانیسم امنیتی است. این راهی است برای سرورها تا به مرورگر بگویند: “دسترسی این منشأ خارجی خاص به منابع من بلامانع است.”
چرا وجود دارد؟
به طور پیشفرض، مرورگرها سیاست منشأ یکسان (SOP) را اجرا میکنند که مانع از خواندن دادههای یک سایت توسط اسکریپتهای سایت دیگر میشود. این کار از خواندن ایمیلهای شما در gmail.com توسط evil.com جلوگیری میکند.
CORS به سرورها اجازه میدهد تا این سیاست را به طور ایمن کاهش دهند. وقتی یک اپلیکیشن وب درخواست کراساورجین ارسال میکند، مرورگر یک هدر Origin میفرستد. سرور با هدر Access-Control-Allow-Origin پاسخ میدهد.
اشتباهات رایج در پیکربندی
- منشأ عمومی (
*): اجازه دادن به همه منشأها. اگرچه برای APIهای عمومی مناسب است، اما اگر باAccess-Control-Allow-Credentials: trueترکیب شود، بسیار خطرناک است. - انعکاس منشأ: تنظیم داینامیک منشأ مجاز بر اساس هدر
Originبدون اعتبارسنجی. این کار عملاً SOP را به طور کامل دور میزند.
بهترین روشها
- دقیق باشید: فقط به دامنههای خاصی که نیاز به دسترسی دارند اجازه دهید.
- در صورت امکان از اعتبارنامهها دوری کنید: اگر API شما نیازی به کوکی یا هدرهای Authorization ندارد، اجازه آنها را ندهید.
- از میانافزارهای امنیتی استفاده کنید: به جای مدیریت دستی هدرها، از کتابخانههای تست شده برای مدیریت پیکربندی CORS استفاده کنید.
مقایسه خلاصه
| ویژگی | SSRF | CSRF | CORS |
|---|---|---|---|
| هدف | منابع سمت سرور | اقدامات سمت کلاینت | دسترسی به دادهها در مرورگر |
| سوءاستفاده از | اعتماد شبکه سرور | رفتار کوکیهای مرورگر | سیاست منشأ یکسان (پیکربندی غلط) |
| دفاع اصلی | لیست سفید و اعتبارسنجی | توکنها و کوکیهای SameSite | پیکربندی صحیح هدرها |
درک این سه ستون امنیت وب برای ساخت اپلیکیشنهای مدرن و مستحکم ضروری است. با اجرای استراتژیهای دفاعی چندلایه، میتوانید هم از زیرساختهای داخلی سرور خود و هم از دادههای خصوصی کاربرانتان محافظت کنید.
ایمن بمانید و از برنامهنویسی لذت ببرید!