ما رسماً بدون PHP شدیم. آنچه اکتبر (تا اینجا) به ما آموخت

هفته ۱۹ تا ۲۴ اکتبر ۲۰۲۶، از دوشنبه تا شنبه، جریانی پیوسته از اخبار امنیتی جدی را در سراسر صنعت به همراه داشت. اگر آن را از دست داده‌اید، مرور ما بر آن هفته جزئیات را پوشش می‌دهد. خلاصه ماجرا: در چندین مورد، مهاجمان پیش از اصلاحیه‌ها دست به کار شدند.

هفته‌ای مثل آن ما را به نقطه صفر برنمی‌گرداند، اما خطوطی را که از پیش روی تخته طراحی است پررنگ‌تر می‌کند. داشتن یک اصل یک چیز است و تماشای اینکه، مورد به مورد، در جایی که آن اصل غایب است چه رخ می‌دهد چیز دیگری است. پس به‌جای فهرست کردن گام‌های فنی، می‌خواهیم اصولی را توضیح دهیم که بر اساس آنها کار می‌کنیم، چون برای شما به‌عنوان مشتری، رویکرد مهم‌تر از هر به‌روزرسانی منفرد است. یکی از این اصول همین حالا به نقطه عطف خود رسیده است: ما اکنون رسماً بدون PHP هستیم.

چرا وصله کردن پس از وقوع، مسابقه‌ای بازنده است؟

سال‌ها توصیه استاندارد ساده بود: سریع وصله کنید تا مشکلی پیش نیاید. روند از همان زمان بر خلاف این توصیه حرکت می‌کرد. تیم Mandiant در Google میانگین فاصله زمانی میان شناخته شدن یک آسیب‌پذیری و سوءاستفاده از آن را اندازه گرفت: ۶۳ روز در ۲۰۱۸ تا ۲۰۱۹، ۳۲ روز در سال‌های ۲۰۲۱ و ۲۰۲۲، و پنج روز در ۲۰۲۳، به‌صورت میانگین و با حذف موارد پرت.

پنج روز رقم سال ۲۰۲۳ است، پیش از آنکه ابزارهای هوش مصنوعی بخشی از کار روزمره نرم‌افزاری شوند. همین ماه اندازه‌گیری تازه‌ای از این مسابقه به ما داد، از سه نقطه دید متفاوت پیرامون افشای PHP2Shell در ۲۱ اکتبر ۲۰۲۶.

تیم اطلاعات تهدید Amazon یک تلاش برای سوءاستفاده از PHP2Shell را در ۱۷ اکتبر، چهار روز پیش از افشای عمومی، مشاهده کرد و می‌گوید به‌محض برداشته شدن ممنوعیت انتشار و عرضه وصله، در عرض چند ساعت کدهای اثبات مفهوم بیشتری پدیدار شدند. F5 Labs نخستین پویش PHP2Shell را بیش از پنج ساعت پیش از انتشار دو CVE (شناسه عمومی آسیب‌پذیری) مشاهده کرد و در عرض چند ساعت پس از افشا، حسگرهایش هزاران تلاش سوءاستفاده ثبت می‌کردند. مدیرعامل Cloudflare، یعنی Matthew Prince، در ۲۲ اکتبر گفت که Cloudflare هزاران تلاش را پیش از اعلام، ده‌ها هزار را در ۴۵ دقیقه پس از آن، صدها هزار را در عرض دو ساعت و میلیون‌ها را تا لحظه انتشار پستش دیده است. اینها تلاش بودند، نه نفوذهای تأییدشده، اما نشان می‌دهند درها با چه سرعتی امتحان می‌شدند: پنجره اکنون با دقیقه و ساعت اندازه‌گیری می‌شود و برای برخی، پیش از آنکه وصله‌ای اصلاً وجود داشته باشد بسته شد.

سوءاستفاده پیش از وجود هر اصلاحیه‌ای نیز نادر نیست. در سال ۲۰۲۳، ۷۰ درصد از آسیب‌پذیری‌های مورد سوءاستفاده‌ای که Mandiant ردیابی کرد، یعنی ۹۷ مورد از ۱۳۸ مورد، به‌صورت روز صفر مورد سوءاستفاده قرار گرفتند، یعنی پیش از آنکه اصلاً اصلاحیه‌ای وجود داشته باشد.

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

چرا به‌جای وصله زدن دور نرم‌افزار، آن را حذف می‌کنیم؟

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

ما نگاه متفاوتی داریم. نرم‌افزاری که نمی‌توان به‌روز نگه داشت حذف می‌شود، نه اینکه دورش وصله بزنیم. آن را با اصلاح‌های موقتی زنده نگه نمی‌داریم، چون اصلاح موقتی روی کد بدون نگهداری، وعده‌ای است که سرانجام شکسته خواهد شد. یا یک جزء تا زمانی که اجرایش می‌کنیم قابل به‌روزرسانی است، یا اصلاً اجرا نمی‌شود.

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

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

سطح حمله کوچک واقعاً چه شکلی است؟

حذف، صریح‌ترین راه برای کوچک کردن آن چیزی است که می‌تواند ضربه بخورد. عادت گسترده‌تر پشت آن نامی فنی دارد: کوچک نگه داشتن سطح حمله. سطح حمله مفهومی ساده است، جمع همه جاهایی که مهاجم می‌تواند کلیدی را در قفلی امتحان کند. هر سرویس در معرض دید، هر کتابخانه شخص ثالث، هر افزونه یک قفل دیگر برای دفاع است. تعریف ما از امنیت خوب از همین‌جا شروع می‌شود: قوی‌ترین کد، کدی است که اجرا نمی‌کنید و امن‌ترین داده، داده‌ای است که هرگز ذخیره نکرده‌اید.

در نظر بگیرید که کتابخانه یا افزونه شخص ثالث واقعاً چیست. وقتی توسعه‌دهنده‌ای یکی را به کار می‌گیرد، به غریبه‌ای، اغلب داوطلبی بی‌مزد، اعتماد می‌کند که آن کد را تا زمانی که اجرا می‌شود امن نگه دارد. کتابخانه به به‌روزرسانی‌های خودش، اصلاحیه‌های امنیتی خودش و نگهدارنده‌ای که حواسش باشد نیاز دارد. اگر آن نگهدارنده علاقه‌اش را از دست بدهد، شغل عوض کند یا به‌سادگی دیگر پاسخ ندهد، کد همچنان کار می‌کند، اما دیگر کسی مراقبش نیست. نقصی که پس از آن نقطه پیدا شود برای همیشه باز می‌ماند، و این همان مشکل رهاشدگی بخش قبلی است که از در کناری وارد می‌شود. این را در تعداد زیاد اجزایی که یک برنامه معمولی به آنها وابسته است ضرب کنید تا تصویر روشن شود. هر وابستگی وعده کوچکی است از سوی کسی که هرگز ندیده‌اید و برخی از این وعده‌ها بی‌سر و صدا منقضی می‌شوند. اجرای تعداد کمتری از آنها یعنی امنیت خود را به غریبه‌های کمتری بدهکار باشید.

سیستم‌هایی که در آنها وارد می‌شوید، از طریقشان پرداخت می‌کنید و برنامه‌های ما با آنها صحبت می‌کنند، به زبان Go نوشته شده‌اند. PHP رفته است و با آن، دنباله بلند کتابخانه‌ها، افزونه‌ها و وابستگی‌هایی که برنامه‌های PHP معمولاً پشت سر خود می‌کشند.

ما Go را برای حیاتی‌ترین سیستم‌هایمان انتخاب کردیم چون مشکل وابستگی را در سطح خود زبان پاسخ می‌دهد. Go از نظر حافظه امن است: زبان، حافظه را به‌جای برنامه‌نویس مدیریت می‌کند و این یک دسته کامل از باگ‌ها مانند سرریز بافر را منتفی می‌کند، و CISA (آژانس امنیت سایبری و امنیت زیرساخت آمریکا) در سند The Case for Memory Safe Roadmaps زبان Go را در میان زبان‌های امن از نظر حافظه فهرست می‌کند. این دسته بزرگ‌تر از آن است که به نظر می‌رسد: پروژه Chromium دریافته است که حدود ۷۰ درصد از باگ‌های امنیتی جدی‌اش مشکلات امنیت حافظه هستند. کتابخانه استاندارد Go بخش بزرگی از نیازهای یک سرویس وب، از جمله رمزنگاری، را پوشش می‌دهد، بنابراین یک سرویس Go به بسته‌های شخص ثالث کمتری نیاز دارد، که یعنی تعداد کمتری از آن وعده‌های غریبه‌ها. رمزنگاری آنقدر جدی گرفته شده که ماژول رمزنگاری خود Go بر اساس استاندارد FIPS 140-3 دولت آمریکا اعتبارسنجی شده است، با گواهی CMVP شماره ۵۲۴۷. و وقتی نقصی در اکوسیستم گسترده‌تر آشکار می‌شود، تیم امنیتی Go یک پایگاه داده آسیب‌پذیری را گردآوری می‌کند و ابزار govulncheck آن فقط آسیب‌پذیری‌های موجود در کدی را گزارش می‌دهد که برنامه واقعاً فراخوانی می‌کند، که هشدارها را کم‌نویز و قابل اقدام نگه می‌دارد.

این موضوع به این دلیل اهمیت دارد که استقرارهای PHP چقدر گسترده و چقدر قدیمی‌اند. W3Techs گزارش می‌دهد که PHP در ۶۹٫۲ درصد از همه وب‌سایت‌هایی که زبان سمت سرورشان را می‌شناسد استفاده می‌شود و ۲۶٫۶ درصد از سایت‌های PHP هنوز روی PHP 7 و ۷٫۷ درصد روی PHP 5 هستند، اندازه‌گیری‌شده در ۲۷ اکتبر ۲۰۲۶. خود پروژه PHP از هر شاخه انتشار به مدت دو سال با اصلاح باگ و اصلاحیه امنیتی و سپس دو سال دیگر فقط با اصلاحیه‌های امنیتی حیاتی پشتیبانی می‌کند. PHP 7 و PHP 5 از همه اینها گذشته‌اند. بخش بزرگی از وب روی کدی اجرا می‌شود که سازندگانش دیگر از آن محافظت نمی‌کنند، و این همان مسابقه بازنده بخش اول است که داوطلبانه واردش شده‌اند.

وب‌سایت ما صفحات ایستایی است که از پیش ساخته شده‌اند و هیچ کد سمت سروری هنگام بازدید شما آنها را تولید نمی‌کند. صفحه‌ای که فقط یک فایل است چیز بسیار کمی برای حمله دارد. در پاسخ به پرسش اینکه چقدر می‌تواند ضربه بخورد، جواب ما این است: تا جایی که از دستمان برمی‌آید، کم.

چه داده‌هایی درباره شما نگه می‌داریم؟

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

ما فقط آنچه را برای اداره یک حساب لازم است می‌خواهیم. سیاست حریم خصوصی ما (به انگلیسی) آن را به‌روشنی فهرست می‌کند: یک نام کاربری، یک نشانی ایمیل، یک گذرواژه رمزگذاری‌شده و نشانی IP استفاده‌شده هنگام ثبت‌نام. پرداخت‌ها از طریق پردازشگرهای پرداخت شخص ثالث انجام می‌شوند، پس اطلاعات کارت شما نزد متخصصانی است که تمام کسب‌وکارشان محافظت از آنهاست، نه نزد ما.

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

همین منطق فراتر از ما نیز صدق می‌کند، چون شرکت‌های دیگر هم مسابقه‌ها را می‌بازند. بسیاری از نشت‌هایی که مردم گرفتارش می‌شوند در فروشگاه‌ها، انجمن‌ها و سرویس‌هایی رخ می‌دهد که مدت‌ها پیش در آنها ثبت‌نام کرده‌اند. به همین دلیل است که هشدارهای نشت داده ارائه می‌دهیم: Data Breach Scanner ما نشت‌های داده شناخته‌شده را برای نشانی ایمیل شما بررسی می‌کند و اگر پیدا شد به شما ایمیل می‌زند، تا بتوانید گذرواژه‌ها را پیش از سوءاستفاده از نشت عوض کنید.

اگر به‌هرحال چیزی خراب شود چه می‌شود؟

پرسش سوم دو نیمه دارد: بازیابی و بستن شکاف. اول بازیابی. برنامه‌ریزی امنیتی خوب روزهای بد را فرض می‌گیرد. سخت‌افزار خراب می‌شود، تأمین‌کنندگان عوض می‌شوند و گاهی حرکت درست این است که به‌سادگی از یک قطعه زیرساخت دست بکشیم.

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

تاب‌آوری ویژگی پرهیاهویی نیست. بیشتر خودش را در ادامه کار کردن چیزها نشان می‌دهد و در این چارچوب، همان چیزی است که نمی‌گذارد یک دور باخته به یک فصل باخته تبدیل شود.

اصلاحیه‌ها با چه سرعتی به سیستم‌های ما می‌رسند؟

نیمه دیگر پرسش سوم سرعت است. هیچ‌کدام از موارد بالا نیاز به وصله کردن را از بین نمی‌برد؛ بلکه باری را که وصله کردن باید حمل کند تغییر می‌دهد. با سطحی کوچک و نرم‌افزاری به‌روز، اعمال یک اصلاحیه کاری عادی است، نه یک پروژه.

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

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

این پرسش‌ها و اصولی که به آنها پاسخ می‌دهند، کنار هم چنین شکلی دارند:

همه اینها برای شما چه معنایی دارد؟

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

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

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