اصول امنیت وب: توضیح SSRF، CSRF و CORS

اصول امنیت وب: توضیح 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) - را با هر درخواست به یک دامنه ارسال می‌کنند.

  1. کاربر وارد bank.com می‌شود.
  2. کاربر یک سایت مخرب evil.com را در تب دیگری باز می‌کند.
  3. سایت evil.com حاوی یک فرم مخفی است که یک درخواست POST به آدرس bank.com/transfer?amount=1000&to=attacker ارسال می‌کند.
  4. مرورگر درخواست را همراه با کوکی نشست کاربر در bank.com ارسال می‌کند.
  5. سایت 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 پیکربندی صحیح هدرها

درک این سه ستون امنیت وب برای ساخت اپلیکیشن‌های مدرن و مستحکم ضروری است. با اجرای استراتژی‌های دفاعی چندلایه، می‌توانید هم از زیرساخت‌های داخلی سرور خود و هم از داده‌های خصوصی کاربران‌تان محافظت کنید.

ایمن بمانید و از برنامه‌نویسی لذت ببرید!