پرش به محتویات

API7:2023 جعل درخواست در سمت سرور(SSRF)

ضعف امنیتی عوامل تهدید / مسیر حمله پیامد
خاص API / قابلیت بهره‌برداری: آسان میزان شیوع: متداول/ قابلیت تشخیص: آسان پیامد فنی: متوسط / خاص کسب و کار
برای بهره‌برداری از این آسیب‌پذیری، مهاجم تابع انتهایی APIی را پیدا کند که به URI مشتری، دسترسی می‌دهد. به طور کلی، SSRF ابتدایی (که بر مبنای feedback حاصل از موفقیت یا شکست حمله طراحی شده) نسبت به SSRF کور راحت‌تر بهره‌برداری می‌شود. مفاهیم جدید در توسعه نرم‌افزارها، توسعه‌دهندگان را تشویق می‌کنند تا از URI های ارائه شده توسط مشتریان استفاده کنند. یکی از مشکلات رایج در اینجا این است که URI ارائه شده توسط مشتری به درستی اعتبارسنجی نشده یا اصلاح نشده باشند. برای تشخیص این مشکل، درخواست‌ها و پاسخ‌های API در روند توسعه و تست برنامه باید تجزیه و تحلیل شوند. وقتی که پاسخی به مشتری برنگشت داده نمی‌شود (مثل SSRF کور)، تشخیص و رفع آسیب‌پذیری نیاز به تلاش و خلاقیت بیشتری دارد. اگر مهاجمی حمله SSRF را با موفقیت انجام دهد، ممکن است به نتایجی نظیر شناسایی خدمات داخلی سرور (مانند اسکن پورت‌ها)، دسترسی به اطلاعات محرمانه افشا شده، دور زدن دیواره‌ی آتش‌ و دیگر مکانیزم‌های امنیتی دست یابد. در برخی موارد، این نوع حمله می‌تواند منجر به اختلال در ارائه سرویس (DoS) شود و باعث شود مهاجم از سرور به عنوان یک پروکسی برای پنهان کردن فعالیت‌های مخرب استفاده کند.

آیا API از نظر جعل درخواست در سمت سرور ‌‌‌آسیب‌پذیر است؟

این آسیب‌پذیری زمانی رخ می‌دهد که یک API بدون اعتبارسنجی URL کاربر، منبعی را از راه دور درخواست می‌کند. این مسئله به مهاجم این امکان را می‌دهد تا اپلیکیشن را وادار کند حتی در صورت داشتن دیوار آتش یا شبکه خصوصی مجازی، درخواست‌هایی ساختگی ایجاد کرده و به مقصدی دور از انتظار ارسال کند. مفاهیم مدرن در توسعه برنامه‌ها باعث می‌شود که مشکلات مربوط به این آسیب‌پذیری رایج‌تر و خطرناک‌تر شوند. - موارد رایج‌تر: مفاهیم زیر، توسعه‌دهندگان را تشویق می‌کنند تا براساس ورودی کاربر به منابع خارجی دسترسی پیدا کنند: وب‌هوک‌ها، دریافت فایل از URLها، سفارشی‌سازی SSO و پیش‌نمایش URLها. - موارد خطرناک‌تر: فناوری‌های مدرن مانند ارائه‌دهندگان فضای ابری، Kubernetes و Docker امکان قرارگیری رابط‌های مدیریت و کنترل را از طریق HTTP روی مسیرهای پیش‌بینی‌پذیر و شناخته‌شده فراهم آورده‌اند. این کانال‌ها مورد هدف مستقیم مهاجمان برای حملات SSRF قرار می‌گیرند. در برنامه‌های مدرن که ارتباطات پیوسته و بدون وقفه با سایر اجزای سیستم دارند، کنترل ترافیک خروجی از برنامه به دلیل پیچیدگی ارتباطات بیشتر چالش‌برانگیز‌ است. خطر SSRF نمی‌تواند به طور کامل از بین برود. بنابراین در هنگام انتخاب یک مکانیزم حفاظتی، مهم است که خطرات و نیازهای تجاری را در نظر گرفت.

مثال‌‌‌‌هایی از سناریوهای حمله

سناریو #1

یک شبکه اجتماعی به کاربران امکان بارگذاری تصویر برای پروفایل کاربری خود را می‌دهد. کاربر می‌تواند تصویر را از دستگاه بارگذاری کرده یا URL آن را وارد کند. در صورت وارد کردن URL، API زیر فراخوانی می‌شود:

POST /api/profile/upload_picture

{
  "picture_url": "http://example.com/profile_pic.jpg"
}

مهاجم می‌تواند URL مخربی را ارسال کرده و با استفاده از تابع انتهایی API، پورت‌های شبکه داخلی را اسکن کند:

{
  "picture_url": "localhost:8080"
}

بر اساس زمان پاسخ‌دهی، مهاجم می‌تواند بفهمد که پورت باز است یا خیر.

سناریو #2

یک محصول امنیتی طوری طراحی شده که وقتی ناهنجاری‌هایی را در شبکه تشخیص دهد، رویدادهای متناسب با آن را تولید می‌کند. برخی از تیم‌ها ترجیح می‌دهند که این رویدادها را در یک سیستم نظارتی عمومی و کلان‌تر مانند SIEM (مدیریت اطلاعات و رویداد امنیتی) بررسی کنند. به این منظور، محصول امنیتی با استفاده از وب‌هوک‌ها امکان ادغام با سایر سیستم‌ها را فراهم می‌آورد.

در جریان ایجاد یک وب‌هوک جدید، یک تغییر GraphQL ارسال می‌شود که شامل مسیر تابع انتهایی SIEM است:

POST /graphql

[
  {
    "variables": {}
    "query": "mutation {
      createNotificationChannel(input: {
        channelName: "ch_piney"
        notificationChannelConfig: {
          customWebhookChannelConfigs: [
            {
              url: "http://www.siem-system.com/create_new_event"
              send_test_req: true
            }
          ]
        }
      }){
        channelId
    }
    }"
  }
]

در طول فرآیند ایجاد وب‌هوک، API پشتیبانی یک درخواست آزمایشی به URL وب‌هوک ارائه شده، ارسال می‌کند و پاسخ را به کاربر نشان می‌دهد.
مهاجم می‌تواند از این فرآیند بهره برده و درخواست API را به منبعی حساس، مانند یک سرویس فهرست متادیتای ابر داخلی که شامل اطلاعات ورود به حساب‌های کاربری است، تغییر دهد:

POST /graphql

[
  {
    "variables": {}
    "query": "mutation {
      createNotificationChannel(input: {
        channelName: "ch_piney"
        notificationChannelConfig: {
          customWebhookChannelConfigs: [
            {
              url: "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm"
              send_test_req: true
            }
          ]
        }
      }) {
        channelId
      }
    }
  }
]

وقتی برنامه پاسخ این درخواست آزمایشی را ارسال می‌کند، مهاجم می‌تواند اطلاعات ورود به حساب کاربری در محیط ابری را مشاهده کند.

چگونه از ‌‌‌آسیب‌پذیری جعل درخواست در سمت سرور پیشگیری کنیم؟

  • جداسازی مکانیزم بازیابی منابع در شبکه‌: محدود کردن امکان دسترسی به منابع داخلی شبکه توسط مکانیزم‌هایی که برای بازیابی منابع از راه دور طراحی شده‌اند.
  • در صورت امکان، از لیست‌های مجاز استفاده شود.
  • الگوهای URL و پورت‌ها
  • انواع رسانه‌های مجاز برای قابلیت‌های خاص
  • غیرفعال کردن بازنشانی‌های HTTP
  • استفاده از یک تجزیه‌کننده URL امتحان شده برای جلوگیری از مشکلات ناشی از عدم انطباق در تجزیه URL
  • اعتبارسنجی و پاکسازی تمام داده‌های ورودی از سوی مشتری
  • عدم ارسال داده خام به مشتری

مراجع

خارجی