تحلیلگران از توصیه های آژانس امنیت ملی برای توسعه دهندگان برای استفاده از زبان های ایمن برای حافظه استقبال می کنند.

تحلیلگران امنیتی هفته گذشته از توصیه آژانس امنیت ملی ایالات متحده (NSA) برای توسعه دهندگان نرم افزار برای در نظر گرفتن استفاده از زبان هایی مانند C#، Go، Java، Ruby، Rust و Swift برای کاهش آسیب پذیری های مربوط به حافظه در کد استقبال کردند.

NSA این زبان ها را به عنوان زبان های «ایمن حافظه» توصیف کرد که حافظه را به طور خودکار به عنوان بخشی از زبان رایانه مدیریت می کنند. NSA گفت که آنها برای اجرای امنیت حافظه به برنامه نویس متکی نیستند و در عوض از ترکیبی از زمان کامپایل و بررسی زمان اجرا برای محافظت در برابر خطاهای حافظه استفاده می کنند.

موردی برای زبان‌های ایمن برای حافظه

مشاوره تا حدودی غیرمعمول NSA در 10 نوامبر به زبان های پرکاربرد مانند C و C++ اشاره کرد. اتکای بیش از حد به برنامه نویسان اشتباهات مربوط به حافظه را مرتکب نشوید، که به آن اشاره شد، همچنان دلیل اصلی آسیب پذیری های امنیتی در نرم افزار است. مطالعات قبلی - یک توسط مایکروسافت در سال 2019 و دیگری از گوگل در سال 2020 به مرورگر کروم مربوط می شود – به عنوان مثال، NSA گفت، برای مثال، هر دو 70 درصد از آسیب پذیری ها مربوط به مسائل ایمنی حافظه هستند.

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

NSA در مشاوره خود گفت: C#، Go، Java، Ruby، Rust، Swift و سایر زبان‌های ایمن برای حافظه خطر این مشکلات را به طور کامل از بین نمی‌برند. به عنوان مثال، اکثر آنها حداقل شامل چند کلاس یا توابع هستند که از نظر حافظه ایمن نیستند و به برنامه نویس اجازه می دهند تا یک عملکرد مدیریت حافظه بالقوه ناایمن را انجام دهد. زبان‌های ایمن برای حافظه گاهی اوقات می‌توانند شامل کتابخانه‌هایی باشند که به زبان‌هایی نوشته شده‌اند که دارای عملکردهای حافظه بالقوه ناامن هستند.

اما حتی با وجود این اخطارها، زبان های ایمن برای حافظه می تواند به کاهش آسیب پذیری در نرم افزار کمک کند NSA گفت که ناشی از مدیریت ضعیف و بی دقت حافظه است.

تیم مکی، استراتژیست امنیتی اصلی در مرکز تحقیقات امنیت سایبری Synopsys، از توصیه NSA استقبال می کند. او می‌گوید استفاده از زبان‌های ایمن برای حافظه در واقع باید پیش‌فرض برای اکثر برنامه‌ها باشد. او می‌گوید: «برای اهداف عملی، تکیه بر توسعه‌دهندگان برای تمرکز بر مسائل مدیریت حافظه به جای برنامه‌نویسی ویژگی‌های جدید جالب، مالیات بر نوآوری را نشان می‌دهد. Mackey می‌گوید با زبان‌های برنامه‌نویسی ایمن برای حافظه و چارچوب‌های مرتبط، این نویسندگان زبان هستند که مدیریت مناسب حافظه را تضمین می‌کنند و نه توسعه‌دهندگان برنامه.

تغییر می تواند چالش برانگیز باشد

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

علاوه بر این، سازمان‌ها باید در نظر بگیرند که چقدر می‌خواهند بین امنیت و عملکرد تسویه حساب کنند. NSA هشدار داد: "ایمنی حافظه از نظر عملکرد و انعطاف پذیری می تواند پرهزینه باشد." برای زبان‌هایی که سطح بالایی از حفاظت ذاتی دارند، به دلیل بررسی‌ها و حفاظت‌ها، ممکن است برای کامپایل کردن برنامه به کار قابل توجهی نیاز باشد.»

مایک پارکین، مهندس فنی ارشد Vulcan Cyber ​​می‌گوید، هنگام تلاش برای انتقال یک برنامه از یک زبان به زبان دیگر، متغیرهای بی‌شماری در بازی وجود دارند. پارکین می‌گوید: «در بهترین حالت، تغییر ساده است و یک سازمان می‌تواند آن را نسبتاً بدون دردسر انجام دهد». در برخی دیگر، برنامه به ویژگی‌هایی متکی است که در زبان اصلی بی‌اهمیت هستند اما برای بازآفرینی در زبان جدید به توسعه گسترده و پرهزینه نیاز دارند.»

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

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

مکی پیشنهاد می‌کند که سازمان‌ها هنگام تغییر زبان، استفاده از میکروسرویس‌ها را در نظر بگیرند. مکی می‌گوید: «با معماری میکروسرویس‌ها، برنامه به مجموعه‌ای از سرویس‌ها تجزیه می‌شود. از دیدگاه یک زبان برنامه نویسی، هیچ چیزی وجود ندارد که ذاتاً ایجاب کند که هر میکروسرویس به همان زبان برنامه نویسی برنامه نویسی شود که سایر سرویس ها در همان برنامه کاربردی هستند.

ایجاد حرکت

داده های اخیر Statista این را نشان می دهد بسیاری از توسعه دهندگان در حال حاضر استفاده می کنند زبان هایی که برای حافظه امن در نظر گرفته می شوند. به عنوان مثال، نزدیک به دو سوم (65.6٪) از جاوا اسکریپت، نزدیک به نیمی (48.06٪) از پایتون، یک سوم از جاوا و نزدیک به 28٪ از C# استفاده می کنند. در عین حال، بخش قابل توجهی هنوز از زبان های ناامن مانند C++ (22.5%) و C (19.25%) استفاده می کنند.

یوهانس اولریچ، رئیس تحقیقات موسسه فناوری SANS می‌گوید: «من فکر می‌کنم بسیاری از سازمان‌ها در حال حاضر از C/C++ نه تنها به خاطر مسئله ایمنی حافظه، بلکه به خاطر سهولت کلی توسعه و نگهداری، کنار گذاشته‌اند. اما همچنان پایه‌های کدهای قدیمی وجود خواهند داشت که باید برای سال‌های آینده حفظ شوند.»

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