متغیرهای محیطی اسکریپت.Dev لو رفت — درسهای امنیتی برای هر کسی که سرویس SaaS استفاده میکنه
نویسنده: آرش لطیفی — موسس The DevArt
در اول نوامبر Trigger.dev فاش کرد مهاجم به environment variables بخشی از مشتریهاش دسترسی پیدا کرده. نشونهها، نقدهای جامعه به واکنششون، و چکلیست عملی برای پروژهی خودت.
TL;DR — هکرها به environment variables بخشی از مشتریهای Trigger.dev دسترسی پیدا کردن؛ اکسپلویت بسته شده ولی پستمورتیم هنوز منتشر نشده. اگر از هر سرویس SaaS (پرداخت، دپلوی، اتوماسیون) استفاده میکنی، رمزها و کلیدهای APIات روی خطن — این چکلیست رو همین امروز اجرا کن.
اول نوامبر ۲۰۲۶، Eric Allam (CTO شرکت Trigger.dev) یه پست کوتاه با عنوان «Security Disclosure: Sunday November 1st» منتشر کرد. متن اصلی فقط چند جمله بود: اکسپلویت بلاک شده، ولی بررسی نشون داده که environment variables یه زیرمجموعه از سازمانها در معرض دسترسی غیرمجاز قرار گرفته. به همهی مالکان حسابهای تحت تاثیر ایمیل زده شده.
دو روز بعد، هنوز هیچ پستمورتیم فنی منتشر نشده — هیچ توضیحی درباره اینکه آسیبپذیری دقیقاً چی بود، چقدر طول کشیده، یا چه کسی مهاجم بوده. این دقیقاً همون چیزیه که بحث HN رو داغ کرد (۱۰۴ امتیاز در زمان نگارش) و درسهای مهمی برای همهی ما داره.
جامعه چطور واکنش نشون داد — و چرا
| انتظار کاربران | اتفاق واقعی | نتیجه | |---|---|---| | پستمورتیم فنی کامل بعد از مهار حادثه | فقط یه پاراگراف + وضعیت resolved | اعتماد آسیب دید | | توضیح محدوده نشت (کدوم کلیدها، چه مدت) | «ایمیل به حسابهای تحت تاثیر» بدون جزئیات عمومی | حدس و گمان | | وضعیت Mitigated تا پایان تحقیق | مستقیم resolved زدن | بحث داغ HN |
نکتههای تیز بحث HN:
- یکی از کاربران پرسید «آیا حتی یکی از این شرکتها آسیبپذیری واقعی رو افشا کرده؟» و جواب برعکس بود: «نه — شاید خودمون هم نمیدونیم.»
- کاربری به اسم whilenot-dev نوشت: «فقط میگن اکسپلویت رو بستن — این یعنی چی؟ API رو آفلاین کردن؟ اکانت مهاجم رو غیرفعال کردن؟ یا باگ واقعاً فیکس شده؟»
- یه کاربر گفت این برخورد باعث شده «دیگه هیچوقت از این سرویس استفاده نکنم یا به کسی توصیه نکنم» — نه بهخاطر خود نفوذ، بلکه بهخاطر نحوهی اطلاعرسانی.
- یه حدس جالب: Northflank گفته که CVE-2026-98432 رو پچ کرده — همین حفرهی TCP کرنل لینوکس — و ممکنه این حمله هم بهش مربوط باشه (تأیید نشده).
چرا environment variables مهمترین چیز توی حسابته؟
اگه پروژهی آنلاین داری — چه فروشگاه باشه چه سرویس — توی env variables معمولاً اینها هست:
- کلیدهای درگاه پرداخت (زرینپال، Stripe و...)
- SMTP یا سرویس ایمیل
- کلیدهای پنل پیامک
- توکنهای ادمین و webhook secretها
یعنی با دسترسی به env vars، مهاجم میتونه مستقیم از درگاه پرداختت برداشت کنه، از SMTPت ایمیل فیشینگ بفرسته، یا webhookهای سرویست رو جعل کنه — بدون اینکه اصلاً به سرور یا کدت دست بزنه.
چکلیست: همین امروز انجام بده
- [ ] کلیدهای API و رمزهای سرویسهای خارجی (درگاه، SMTP، پیامک) رو همین الان rotate کن — حتی اگه از Trigger.dev استفاده نمیکنی. توی بحث HN کاربری درست گفت: «مشتریهاست که وقتی رمزهاشون rotate بشه حادثه تموم میشه.»
- [ ] توی لاگ درگاه پرداختت دنبال تراکنش ناشناس بگرد — مخصوصاً برداشت یا تسویه به حسابهای ناشناس.
- [ ] دسترسیهای ادمین و توکنهای طولانیمدت رو مرور کن؛ هر کلیدی که مدتها استفاده نشده رو باطل کن.
- [ ] دنبال ایمیل رسمی از سرویسهایی که استفاده میکنی بگرد — ولی روی لینکهای داخل ایمیل کلیک نکن؛ مستقیم توی پنل خودت چک کن.
- [ ] یک روتین داشته باش: هر سه ماه یه بار، همهی کلیدها rotate بشن. یه ساعت کاره، ولی یه نشت کامل رو خنثی میکنه.
- [ ] اگه خودت سرویس میدی، نقشهی بحران داشته باش: قبل از زدن resolved، پستمورتیم منتشر کن. درس Trigger.dev اینه که سرعت اطلاعرسانی بدون شفافیت، از خود حادثه بیشتر خراب میکنه.
درس ارتباطی: «resolved» یعنی چی؟
بزرگترین جر بحث، وضعیت status page بود که خیلی زود resolved شد. کاربر tuwtuwtuwtuw وقتی پرسیدید «بعد از فیکس و اطلاع به مشتریها، بازم ناراحت میشید چون resolved زدن؟» جواب داد: «آره.» یعنی مشتریها انتظار دارن حادثهی امنیتی وقتی بسته بشه که:
۱. علت ریشهری مشخص و فیکس شده باشه (عمومی) ۲. پستمورتیم منتشر شده باشه ۳. اقدامات جلوگیری برای آینده تعریف شده باشه
برای کسبوکار کوچیک این یعنی: اگه روزی حساب یا سرورت لو رفت، شفافیت کامل (حتی خبر بد) از سکوت بهتره. سکوت حداکثر ۴۸ ساعت دووم داره — بعدش جامعه خودش حدس میزنه و حدسها همیشه بدتر از واقعیتن.
Q: من از Trigger.dev استفاده نمیکنم؛ به من ربطی داره؟
آره، به دو دلیل: اول، هر سرویس SaaS با دسترسی به env variables ممکنه قربانی مشابه بشه. دوم، کلیدهایی که به هر سرویس خارجی دادی (درگاه پرداخت، ایمیل) اگه اون سرویس لو بره، کلیدهای تو هم در خطرن — برای هر سرویس کلید جدا و کم-دسترسی بساز.
Q: چطور بفهمم کلیدهای من لو رفته؟
سه راه عملی: لاگ استفادهی هر کلید رو چک کن (اکثر سرویسها آخرین استفاده رو نشون میدن)، تراکنشها و ایمیلهای خروجی رو دنبال فعالیت ناشناس بگرد، و اگه شک داری rotate کن — هزینهی rotate کردن چند دقیقهست، هزینهی نشت پرداخت میتونه کل فروشگاهت باشه.
Q: بهترین روش نگهداری env variables امنه؟
اصول پایه: هر سرویس یه کلید مجزا با حداقل دسترسی لازم؛ هیچ کلید اصلی (master) توی سرویسهای ثالث ذخیره نشه؛ rotation دورهیی (هر ۳ ماه)؛ و برای production از secret manager یا env varهای خود هاست استفاده کن، نه فایل .env کامیتشده توی گیت.