GLOS · واژه‌نامه سرنام بحرانی

Sandbox Escape — فرار از سندباکس

Sandbox Escape

فرار از جعبه‌شنی (Sandbox Escape) یعنی گریختن کدِ محدودشده از محیطِ ایزوله‌ای که قرار بوده آن را مهار کند — از سندباکس مرورگر تا فرار از کانتینر و سندباکسِ سطحِ زبان.

تیم فنی پی‌هانتر

جعبه‌شنی چیست و فرار از آن یعنی چه؟

جعبه‌شنی (Sandbox) محیطی محدود و ایزوله است که کدِ نامعتمد را طوری اجرا می‌کند که نتواند به منابع بیرونِ آن محیط دست بزند. ایده این است که حتی اگر کد مخرب باشد، در همان جعبه محبوس بماند. فرار از جعبه‌شنی یعنی مهاجم مرزِ این ایزوله‌سازی را می‌شکند و به منابعی می‌رسد که نباید — از حافظه و فایل‌سیستمِ میزبان تا شبکه.

جعبه‌شنی در سطوح مختلفی از استکِ وب حضور دارد و فرار از هرکدام پیامدِ متفاوتی دارد. مهم‌ترین اصل این است که هر محیطی که «سندباکس» نامیده می‌شود لزوماً یک مرز امنیتی نیست؛ همین سوءتفاهم منشأ بسیاری از باورهای غلط است.

انواع جعبه‌شنی

  • سندباکس مرورگر: مرورگرها هر تب/سایت را در فرایندی جدا و کم‌امتیاز اجرا می‌کنند تا یک صفحه‌ی مخرب نتواند به سیستم‌عامل یا دیگر سایت‌ها دست بزند. فرار از آن معمولاً به یک باگِ حافظه در موتور مرورگر نیاز دارد و از شدیدترین آسیب‌پذیری‌هاست؛ به همین دلیل هم جوایز روزِصفرِ سنگین دارد.
  • فرار از کانتینر (Container Escape): گریختن از داخل کانتینر (مثلاً Docker) به میزبان. علل رایج: کانتینرِ ممتاز (privileged)، سوکتِ Docker متصل‌شده به داخل کانتینر، قابلیت‌های اضافی هسته، یا نقص در زمانِ اجرا. برای برنامه‌های وبِ کانتینری این یک مسیرِ جدیِ ارتقای اثر پس از RCE است.
  • سندباکس سطحِ زبان: محیط‌هایی که قرار است کدِ زبان (JavaScript، Python، …) را محدود اجرا کنند — مثل ماژول vm در Node یا سندباکس موتورهای قالب. تاریخِ این‌ها پر از فرار است.

سندباکس AngularJS — نمونه‌ای که مرز امنیتی نبود

باور غلط رایج

«سندباکس AngularJS یک مرز امنیتی است.» این جمله در محتوای فارسی زیاد تکرار می‌شود و نادرست است. AngularJS (نسخه‌ی ۱.x) سازوکاری به‌نام سندباکس داشت که قصدش محدودکردنِ عباراتِ قالب بود، اما این سازوکار بارها و بارها دور زده شد — یکی از دورزدن‌های شناخته‌شده تغییرِ charAt برای شکستنِ بررسی‌کننده‌ی هویت بود. تیمِ Angular سرانجام به این نتیجه رسید که این سندباکس هرگز یک مرز امنیتی نبوده و آن را در Angular 1.6 دقیقاً به همین دلیل حذف کرد. درسِ عملی روشن است: به سندباکسِ داخلیِ خودِ موتور اتکا نکنید. همین درس در SSTI هم تکرار می‌شود.

این موضوع مستقیماً به تزریق قالب سمت کلاینت (Client-Side Template Injection) گره می‌خورد: اگر ورودی کاربر به‌جای داده به خودِ قالب برسد، کدگذاری HTML بی‌فایده است چون فریم‌ورک پیش از اجرا، محتوا را رمزگشایی می‌کند.

سناریوی واقعی و کشف در تست نفوذ

در یک برنامه‌ی قدیمی مبتنی بر AngularJS 1.5، فیلدِ جستجو مستقیماً داخل یک عبارتِ قالب رندر می‌شود. اینجا انتخابِ بارِ اثباتی اهمیت دارد: {{constructor.constructor('return 1')()}} روی ۱.۶ به بعد کار می‌کند — یعنی جایی که سندباکس اصلاً حذف شده — و روی ۱.۵ توسط ensureSafeFunction() مسدود می‌شود. برای نشان دادنِ دور زدنِ سندباکس روی ۱.۵ باید از بارِ کلاسیکِ همان دوره استفاده کرد: 'a'.constructor.prototype.charAt=[].join. تستر با اجرای موفق آن نشان می‌دهد که سندباکس دور زده شده — که در عمل به XSS اجرایی ختم می‌شود. در سمتِ کانتینر، تستر بررسی می‌کند که آیا کانتینرِ برنامه با پرچمِ privileged اجرا شده یا سوکتِ Docker به آن متصل است؛ این‌ها مسیرهای متداولِ فرار پس از دستیابی به اجرای کد داخل کانتینرند. برای این ارزیابی‌ها دانشِ امنیت برنامه‌ی وب و پیکربندی زیرساخت لازم است.

نکته‌ی مهم در روش کار این است که فرار از جعبه‌شنی به‌ندرت گامِ اول است؛ معمولاً پس از یک اجرای کدِ محدودشده می‌آید و به تستر اجازه می‌دهد اثرِ آن را از «داخل جعبه» به «کنترلِ میزبان» ارتقا دهد. به همین دلیل در گزارش، فرارِ سندباکس معمولاً یافته‌ای است که شدتِ یک آسیب‌پذیریِ دیگر را چند برابر می‌کند.

ارتباط با OWASP و CWE

فرار از جعبه‌شنی یک دسته‌ی مستقل OWASP نیست، اما به چند دسته می‌رسد: پیکربندیِ نادرستِ کانتینر زیر A02:2025 (پیکربندی نادرست) قرار می‌گیرد، فرارِ مبتنی بر عبارتِ قالب زیر A05 (تزریق) و طراحیِ متکی بر سندباکسِ ناکافی زیر A06 (طراحی ناامن). CWEهای مرتبط، بسته به مسیرِ فرار متفاوت‌اند: CWE-693 (شکست سازوکار حفاظتی) برای دور زدنِ خودِ سندباکس، و CWE-269 (مدیریت نادرست سطح دسترسی) برای فرارِ کانتینر از راه اجرای privileged. توجه کنید که CWE-265 منسوخ شده و نباید در گزارش استفاده شود؛ ارجاع به آن در ابزارهای تریاژ به‌عنوان شناسه‌ی نامعتبر علامت می‌خورد.

پرسش‌های متداول

آیا سندباکس AngularJS یک مرز امنیتی بود؟

خیر. AngularJS 1.x سازوکاری به‌نام سندباکس داشت اما بارها دور زده شد و تیم Angular آن را در نسخه‌ی 1.6 حذف کرد، دقیقاً چون به این نتیجه رسیدند که هرگز یک مرز امنیتی نبوده است. نباید به آن اتکا کرد.

فرار از کانتینر چطور رخ می‌دهد؟

معمولاً از راه پیکربندی نادرست: کانتینرِ privileged، متصل‌کردنِ سوکت Docker به داخل، قابلیت‌های اضافی هسته، یا نقص در زمانِ اجرا. برای برنامه‌های وبِ کانتینری، این مسیرِ ارتقای اثر پس از اجرای کد داخل کانتینر است.

فرار از سندباکس مرورگر چقدر جدی است؟

بسیار جدی. معمولاً به یک باگِ حافظه در موتور مرورگر نیاز دارد و اجازه می‌دهد یک صفحه‌ی وب مخرب به سیستم‌عامل کاربر دست بزند. این آسیب‌پذیری‌ها جزو گران‌ترین روزِصفرها هستند و تنها دفاعِ کاربر، به‌روزرسانی مرورگر است.

پیشگیری / رفع

پیشگیری بر اساس نوع:

  • مرورگر: مرورگرها را به‌روز نگه دارید؛ فرار از سندباکس مرورگر معمولاً باگِ حافظه است و وصله تنها دفاع کاربر است.
  • کانتینر: کانتینر را غیرِ privileged اجرا کنید، سوکتِ Docker را داخل کانتینر متصل نکنید، قابلیت‌های هسته را حذف کنید (drop capabilities)، فایل‌سیستم را فقط‌خواندنی کنید و از پروفایل‌های seccomp/AppArmor استفاده کنید.
  • سطح زبان و قالب: به سندباکسِ داخلیِ موتور اتکا نکنید — همان درسِ AngularJS. اگر اجرای کدِ کاربر الزام محصول است، آن را در فرایند/ماشینِ کاملاً جدا و بدون دسترسی به فایل‌سیستم و شبکه اجرا کنید.
  • ورودی کاربر را هرگز به خودِ قالب نرسانید؛ از موتورهای منطق‌گریز استفاده کنید.
  • اصلِ کمترین امتیاز و جداسازیِ لایه‌ها در طراحی.
→ بازگشت به دانشنامه
PUT IT TO THE TEST

امنیت سامانه‌ی شما را
به مهاجمان واگذار نکنید

تیم پی‌هانتر با دیدِ یک مهاجم واقعی، این آسیب‌پذیری‌ها و ده‌ها مورد دیگر را روی دارایی‌های شما می‌سنجد.