सुरक्षा विश्लेषकों ने सॉफ्टवेयर डेवलपर्स के लिए कोड में मेमोरी से संबंधित कमजोरियों को कम करने के लिए सी #, गो, जावा, रूबी, रस्ट और स्विफ्ट जैसी भाषाओं को अपनाने पर विचार करने के लिए पिछले हफ्ते यूएस नेशनल सिक्योरिटी एजेंसी (एनएसए) की सिफारिश का स्वागत किया।
एनएसए ने इन्हें "मेमोरी सेफ" भाषाओं के रूप में वर्णित किया है जो कंप्यूटर भाषा के हिस्से के रूप में मेमोरी को स्वचालित रूप से प्रबंधित करती हैं। एनएसए ने कहा कि वे मेमोरी सुरक्षा को लागू करने के लिए प्रोग्रामर पर भरोसा नहीं करते हैं और इसके बजाय मेमोरी त्रुटियों से बचाने के लिए कंपाइल टाइम और रन टाइम चेक के संयोजन का उपयोग करते हैं।
स्मृति-सुरक्षित भाषाओं का मामला
एनएसए की 10 नवंबर की कुछ असामान्य सलाह सी और सी ++ जैसी व्यापक रूप से इस्तेमाल की जाने वाली भाषाओं की ओर इशारा करती है प्रोग्रामर पर बहुत अधिक भरोसा करना मेमोरी से संबंधित गलतियाँ न करना, जो कि यह नोट किया गया है, सॉफ्टवेयर में सुरक्षा कमजोरियों का शीर्ष कारण बना हुआ है। पिछले अध्ययन - एक के बाद एक 2019 में Microsoft और दूसरे से 2020 में गूगल एनएसए ने कहा कि इसके क्रोम ब्राउजर से संबंधित- उदाहरण के लिए, दोनों ने पाया कि 70% कमजोरियां स्मृति सुरक्षा के मुद्दे थे।
एनएसए ने कहा, "आमतौर पर इस्तेमाल की जाने वाली भाषाएं, जैसे कि सी और सी ++, स्मृति प्रबंधन में बहुत अधिक स्वतंत्रता और लचीलापन प्रदान करती हैं, जबकि स्मृति संदर्भों पर आवश्यक जांच करने के लिए प्रोग्रामर पर बहुत अधिक निर्भर करती हैं।" यह अक्सर बफर अतिप्रवाह त्रुटियों, स्मृति आवंटन मुद्दों और दौड़ की स्थिति जैसी सरल गलतियों से बंधी शोषक कमजोरियों के परिणामस्वरूप होता है।
एनएसए ने अपनी सलाह में कहा कि सी #, गो, जावा, रूबी, रस्ट, स्विफ्ट और अन्य मेमोरी-सुरक्षित भाषाएं इन मुद्दों के जोखिम को पूरी तरह खत्म नहीं करती हैं। उनमें से अधिकांश, उदाहरण के लिए, कम से कम कुछ वर्गों या कार्यों को शामिल करते हैं जो गैर-स्मृति सुरक्षित हैं और प्रोग्रामर को संभावित रूप से असुरक्षित स्मृति प्रबंधन कार्य करने की अनुमति देते हैं। मेमोरी-सुरक्षित भाषाओं में कभी-कभी उन भाषाओं में लिखी गई लाइब्रेरी भी शामिल हो सकती हैं जिनमें संभावित रूप से असुरक्षित मेमोरी फ़ंक्शन होते हैं।
लेकिन इन चेतावनियों के साथ भी, स्मृति-सुरक्षित भाषाएँ सॉफ्टवेयर में कमजोरियों को कम करने में मदद कर सकता है एनएसए ने कहा कि खराब और लापरवाह स्मृति प्रबंधन के परिणामस्वरूप।
Synopsys साइबर सुरक्षा अनुसंधान केंद्र के प्रमुख सुरक्षा रणनीतिकार टिम मैके ने NSA की अनुशंसा का स्वागत किया है। स्मृति-सुरक्षित भाषाओं का उपयोग, वास्तव में, अधिकांश अनुप्रयोगों के लिए डिफ़ॉल्ट होना चाहिए, वे कहते हैं। "व्यावहारिक उद्देश्यों के लिए, अच्छी नई सुविधाओं की प्रोग्रामिंग के बजाय स्मृति प्रबंधन के मुद्दों पर ध्यान केंद्रित करने के लिए डेवलपर्स पर निर्भर रहना नवाचार पर एक कर का प्रतिनिधित्व करता है," वे कहते हैं। मैके कहते हैं, स्मृति-सुरक्षित प्रोग्रामिंग भाषाओं और संबंधित ढांचे के साथ, यह भाषा के लेखक हैं जो उचित स्मृति प्रबंधन सुनिश्चित करते हैं न कि एप्लिकेशन डेवलपर्स।
पारी चुनौतीपूर्ण हो सकती है
एनएसए ने स्वीकार किया कि एक परिपक्व सॉफ्टवेयर विकास वातावरण को एक भाषा से दूसरी भाषा में स्थानांतरित करना कठिन हो सकता है। प्रोग्रामर को नई भाषा सीखने की आवश्यकता होगी, और प्रक्रिया के दौरान नौसिखियों की गलतियाँ और दक्षता हिट होने की संभावना है। उपलब्ध स्मृति सुरक्षा की सीमा भी भाषा के अनुसार महत्वपूर्ण रूप से भिन्न हो सकती है। कुछ केवल न्यूनतम मेमोरी सुरक्षा प्रदान कर सकते हैं, जबकि अन्य मेमोरी एक्सेस, आवंटन और प्रबंधन के लिए काफी सुरक्षा प्रदान करते हैं।
इसके अलावा, संगठनों को यह विचार करने की आवश्यकता होगी कि वे सुरक्षा और प्रदर्शन के बीच कितना समझौता करने को तैयार हैं। एनएसए ने चेतावनी दी, "प्रदर्शन और लचीलेपन में मेमोरी सुरक्षा महंगी हो सकती है।" "अंतर्निहित सुरक्षा के चरम स्तर वाली भाषाओं के लिए, चेक और सुरक्षा के कारण कार्यक्रम को संकलित करने के लिए काफी काम की आवश्यकता हो सकती है।"
वल्कन साइबर के वरिष्ठ तकनीकी इंजीनियर माइक पार्किन कहते हैं, जब एक भाषा से दूसरी भाषा में किसी एप्लिकेशन को पोर्ट करने की कोशिश की जाती है, तो खेलने में असंख्य चर होते हैं। पार्किन कहते हैं, "सबसे अच्छी स्थिति में बदलाव सरल है, और एक संगठन इसे अपेक्षाकृत दर्द रहित रूप से पूरा कर सकता है।" "दूसरों में, एप्लिकेशन उन विशेषताओं पर निर्भर करता है जो मूल भाषा में तुच्छ हैं लेकिन नए में फिर से बनाने के लिए व्यापक और महंगे विकास की आवश्यकता होती है।"
मैके चेतावनी देते हैं कि स्मृति-सुरक्षित भाषाओं का उपयोग भी उचित सॉफ़्टवेयर परीक्षण की आवश्यकता को प्रतिस्थापित नहीं करता है। सिर्फ इसलिए कि प्रोग्रामिंग भाषा स्मृति सुरक्षित है इसका मतलब यह नहीं है कि उस पर विकसित भाषा या अनुप्रयोग बग से मुक्त हैं।
एक प्रोग्रामिंग भाषा से दूसरी भाषा में जाना एक जोखिम भरा प्रस्ताव है जब तक कि आपके पास ऐसा कर्मचारी न हो जो पहले से ही पुरानी भाषा और नई भाषा दोनों को समझता हो, मैके कहते हैं। “इस तरह का माइग्रेशन सबसे अच्छा तब होता है जब एप्लिकेशन एक प्रमुख संस्करण अपडेट से गुजर रहा हो; अन्यथा इस बात की संभावना है कि माइग्रेशन प्रयास के हिस्से के रूप में अनजान बग पेश किए जाते हैं, "उन्होंने नोट किया।
मैके का सुझाव है कि भाषा बदलने की बात आने पर संगठन माइक्रोसर्विसेज का उपयोग करने पर विचार करते हैं। मैके कहते हैं, "एक माइक्रोसर्विस आर्किटेक्चर के साथ, एप्लिकेशन को कंटेनरीकृत सेवाओं के एक सेट में विघटित किया जाता है।" "एक प्रोग्रामिंग भाषा के दृष्टिकोण से, ऐसा कुछ भी नहीं है जो स्वाभाविक रूप से आवश्यक हो कि प्रत्येक माइक्रोसर्विस को उसी प्रोग्रामिंग भाषा में उसी एप्लिकेशन के भीतर अन्य सेवाओं के रूप में प्रोग्राम किया जाए।"
ले जाना
स्टेटिस्टा के हालिया डेटा से पता चलता है कई डेवलपर पहले से ही उपयोग कर रहे हैं भाषाएँ जिन्हें स्मृति सुरक्षित माना जाता है। लगभग दो-तिहाई (65.6%), उदाहरण के लिए, जावास्क्रिप्ट का उपयोग करते हैं, लगभग आधे (48.06%) पायथन का उपयोग करते हैं, एक तिहाई जावा का उपयोग करते हैं, और लगभग 28% C# का उपयोग करते हैं। इसी समय, एक बड़ा अनुपात अभी भी असुरक्षित भाषाओं जैसे सी ++ (22.5%) और सी (19.25%) का उपयोग कर रहा है।
SANS टेक्नोलॉजी इंस्टीट्यूट में शोध के डीन जोहान्स उलरिच कहते हैं, "मुझे लगता है कि कई संगठन न केवल मेमोरी सुरक्षा के मुद्दे के लिए, बल्कि विकास और रखरखाव की समग्र आसानी के लिए भी C / C ++ से दूर जा रहे हैं।" "लेकिन अभी भी विरासत कोड आधार होंगे जिन्हें आने वाले कई वर्षों तक बनाए रखना होगा।"
एनएसए की सलाह ने इस मोड़ पर इसकी सिफारिश को प्रेरित करने के लिए बहुत कम अंतर्दृष्टि प्रदान की। लेकिन नेटेनरिच के प्रमुख थ्रेट हंटर जॉन बम्बेनेक सलाह देते हैं कि संगठन इसे नज़रअंदाज़ न करें। "1990 के दशक से स्मृति भेद्यता और हमले व्यापक रहे हैं, इसलिए सामान्य तौर पर, यह अच्छी सलाह है," वे कहते हैं। "जैसा कहा जा रहा है, जैसा कि यह एनएसए से आ रहा है, मेरा मानना है कि इस सलाह को और अधिक अत्यावश्यक होना चाहिए और यह उस ज्ञान से संचालित हो रहा है जो उनके पास है और हमारे पास नहीं है।"
