سخت‌سازی مرزها: پیشگیری از SSRF در معماری‌های بومی ابری

فریب درخواست سمت سرور (SSRF) همچنان یکی از حیاتی‌ترین اما اغلب نادیده گرفته شده‌ترین آسیب‌پذیری‌ها در توسعه برنامه‌های مدرن است. در حالی که SSRF سنتی به مهاجمان اجازه می‌داد شبکه‌های داخلی را اسکن کنند، ظهور فناوری‌های بومی ابری سطح حمله را تغییر داده است. امروز، هدف اصلی فقط پایگاه‌های داده داخلی نیست، بلکه خدمات متادیتای زیرساخت خود ارائه‌دهنده ابری است. این مطلب بررسی می‌کند که چگونه می‌توان با معماری مناسب، با محافظت در برابر سوءاستفاده از متادیتای ابری و کنترل دقیق خروجی ابرخصوصی مجازی (VPC)، از SSRF جلوگیری کرد.

تله متادیتای ابری

در محیط‌های سنتی داخلی (On-Premise)، یک آسیب‌پذیری SSRF ممکن است به مهاجم اجازه دهد به پنل‌های مدیریت داخلی یا APIهای خصوصی دسترسی پیدا کند. در محیط‌های ابری، خطرات به طور نمایی افزایش می‌یابد. بیشتر ارائه‌دهندگان ابری، از جمله AWS، Azure و GCP، متادیتای نمونه‌ها را از طریق یک آدرس IP غیرقابل مسیریابی و شناخته شده (مانند 169.254.169.254) در دسترس قرار می‌دهند. این نقطه پایانی حاوی داده‌های حساسی از جمله اعتبارنامه‌های نقش IAM، توکن‌های ثبت نام کانتینر و جزئیات پیکربندی نمونه است.

اگر برنامه شما URLهای ارائه شده توسط کاربر را می‌پذیرد و آن‌ها را بدون اعتبارسنجی دریافت می‌کند، مهاجم می‌تواند یک پیکربندی (Payload) هدف قرار دادن خدمات متادیتا ایجاد کند. برای مثال:

// نمونه کد آسیب‌پذیر
const url = req.query.target; // ورودی کاربر
await axios.get(url); // خطرناک! بدون اعتبارسنجی

یک مهاجم می‌تواند درخواستی به http://169.254.169.254/latest/meta-data/iam/security-credentials/ ارسال کند تا اعتبارنامه‌های موقت را استخراج نماید و به طور بالقوه کنترل کاملی بر روی نمونه و هر منبع دیگری که نقش IAM مرتبط می‌تواند به آن دسترسی پیدا کند، به دست آورد.

پیاده‌سازی اعتبارسنجی سخت‌گیرانه URL

خط مقدم دفاع، اعتبارسنجی ورودی قوی است. توسعه‌دهندگان باید فهرست‌های سفید (Allowlists) سخت‌گیرانه‌ای برای پروتکل‌ها، دامنه‌ها و محدوده‌های IP پیاده‌سازی کنند. هرگز به فهرست‌های سیاه (Blocklists) تکیه نکنید، زیرا آن‌ها به راحتی از طریق حملات بازنویسی DNS یا مستندات IP خاص ابری دور زده می‌شوند.

هنگام پیاده‌سازی اعتبارسنجی URL، اطمینان حاصل کنید که:

• فقط پروتکل‌های https را به صراحت مجاز کنید تا از شنود متن ساده جلوگیری شود.
• آدرس IP حل شده را اعتبارسنجی کنید تا اطمینان حاصل شود که در محدوده‌های خصوصی RFC1918 یا محدوده‌های متادیتای ابری قرار ندارد.
• هدایت خودکار (Redirect) را غیرفعال کنید، زیرا مهاجمان اغلب از هدایت‌ها برای دور زدن بررسی‌های اولیه دامنه استفاده می‌کنند.

در اینجا یک نمونه Node.js با استفاده از یک کتابخانه اعتبارسنجی آورده شده است:

const isSafeUrl = (urlString) => {
  const url = new URL(urlString);
  
  // مسدود کردن غیر HTTPS
  if (url.protocol !== 'https:') return false;
  
  // مسدود کردن محدوده‌های IP خصوصی و IPهای متادیتای ابری
  const privateIPs = [
    '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16',
    '169.254.169.254' // متادیتای AWS
  ];
  
  const resolvedIP = dns.resolveSync(url.hostname);
  if (privateIPs.some(ipRange => isInRange(resolvedIP, ipRange))) {
    return false;
  }
  
  return true;
};

ایمن‌سازی خروجی VPC با نقاط پایانی سرویس

اعتبارسنجی در سطح برنامه حیاتی است، اما به تنهایی کافی نیست. شما باید امنیت را در لایه شبکه اعمال کنید. یک اصل اساسی امنیت ابری، مدل شبکه «اعتماد صفر» (Zero-Trust) است که به ترافیک خروجی اعمال می‌شود. بیشتر منابع ابری نباید هرگز دسترسی مستقیم به اینترنت داشته باشند. در عوض، آن‌ها باید از طریق کانال‌های خصوصی با سرویس‌های خارجی تعامل داشته باشند.

استفاده از Private Link و نقاط پایانی VPC

برای سرویس‌هایی مانند S3، DynamoDB یا SQS، هرگز ترافیک را از طریق اینترنت عمومی مسیریابی نکنید. از نقاط پایانی VPC (به طور خاص نقاط پایانی Interface یا Gateway) استفاده کنید تا ترافیک در داخل شبکه AWS باقی بماند. این کار خطر دور زدن مهاجمان SSRF از طریق سرویس‌های عمومی برای رسیدن به منابع داخلی ابری را از بین می‌برد.

علاوه بر این، گروه‌های امنیتی (Security Groups) و ACLهای شبکه خود را طوری پیکربندی کنید که به طور پیش‌فرض ترافیک خروجی را رد کنند. فقط اجازه خروج به دامنه‌ها یا IPهای خاص فهرست سفید شده که برای منطق کسب‌وکار ضروری هستند را مجاز کنید. این کار به طور قابل توجهی شعاع انفجار (Blast Radius) را در صورت کشف یک آسیب‌پذیری SSRF کاهش می‌دهد.

نتیجه‌گیری

پیشگیری از SSRF در برنامه‌های بومی ابری نیازمند یک استراتژی دفاع در عمق است. تکیه صرف بر اعتبارسنجی کد در سطح برنامه کافی نیست. با ترکیب فهرست‌های سفید سخت‌گیرانه URL، غیرفعال کردن هدایت‌ها و معماری VPC خود برای محدود کردن ترافیک خروجی از طریق نقاط پایانی خصوصی، می‌توانید تهدید سوءاستفاده از خدمات متادیتا را به طور مؤثر خنثی کنید. همان‌طور که معماری‌های ابری پیچیده‌تر می‌شوند، ایمن‌سازی مرز بین برنامه شما و زیرساخت پایه باید همواره در اولویت اصلی مهندسان و توسعه‌دهندگان امنیت قرار گیرد.