RubyRussia 2019. मिखाइल Pronyakin: रूबी सुरक्षित है?

RubyRussia सम्मेलन में कोड लिखने और दूसरों की तुलना में इसे बेहतर बनाने के लिए कई वार्ताएं होंगी । लेकिन अगर आपकी कंपनी द्वारा लॉन्च किया गया उत्पाद असुरक्षित है, तो इससे बड़ी समस्याएं हो सकती हैं। ग्रिगोरी पेत्रोव ने इस महत्वपूर्ण विषय पर एकीकृत वेलारम मंच के डेवलपर, ओएनएसईके कंपनी के मिखाइल प्रोनायकिन के साथ चर्चा की।


मुझे बताएं कि आप क्या करते हैं और आप रूबी का उपयोग कैसे करते हैं?

एक बार, मैंने सूचना सुरक्षा के क्षेत्र में एक विशेषज्ञ के रूप में काम किया। वेब एप्लिकेशन और विभिन्न भौतिक उपकरणों के पंचक जैसा कुछ किया। इसके समानांतर, वह उस समय सी में सिस्टम प्रोग्रामिंग में लगे हुए थे, अब के रूप में, मेटस्प्लोइट फ्रेमवर्क लोकप्रिय था, जिसे कमजोरियों की खोज और दोहन के लिए अपने स्वयं के मॉड्यूल के साथ विस्तारित किया जा सकता था। यह रूबी में लिखा गया था - इसलिए इस भाषा से मेरा परिचय शुरू हुआ। फिर मैं ओन्सेक के लिए काम करने गया, जहां पहले तो मैंने रूबी से सी के कोड को फिर से लिखकर प्रोजेक्ट बैकेंड के कुछ महत्वपूर्ण हिस्सों को गति दी, और फिर मैंने केवल रूबी में नई कार्यक्षमता लिखना शुरू किया। हमारी कंपनी की गतिविधियाँ सूचना सुरक्षा से संबंधित हैं, हम Valarm कर रहे हैं , जो वेब अनुप्रयोगों की सुरक्षा और परीक्षण के लिए एक मंच है (और न केवल)। यह पता चला है कि मैं रूबी डेवलपर और सूचना सुरक्षा विशेषज्ञ दोनों हूं।

आपकी रिपोर्ट इस विषय से संबंधित होगी। मुझे और बताओ।

आरओआर प्रोग्रामर को कोड लिखने का बहुत अच्छा अवसर देता है, लेकिन इसमें ऐसे स्पष्ट बिंदु भी होते हैं जो सुरक्षा समस्याओं को जन्म दे सकते हैं। सम्मेलन में, मैं रूबी अनुप्रयोगों की विशिष्ट कमजोरियों के बारे में बात करूंगा और व्यावहारिक उदाहरण दूंगा जो गलतियों को रोकने में मदद करेगा।

आपकी राय में, सुरक्षा की दृष्टि से अब रेल कैसी है?

रूबी और रेल के दर्शन में, "कॉन्फ़िगरेशन पर समझौते की प्राथमिकता" जैसी कोई चीज है। अगर समझौते में सबकुछ सोच लिया जाता है, तो कोई सुरक्षा समस्याएं सामने नहीं आएंगी। लेकिन अगर अचानक ऐसी स्थिति उत्पन्न होती है कि आप डिफ़ॉल्ट रूप से असुरक्षित कोड लिख सकते हैं, तो यह पहले से ही गंभीर समस्याएं पैदा कर सकता है। विशेष रूप से नौसिखिए डेवलपर्स के लिए जिन्होंने सिर्फ रेल सीखना शुरू किया और अपने कोड की सुरक्षा के बारे में भी नहीं सोचते। अतीत को देखते हुए, यह अब तक की सुरक्षा के साथ हर जगह बदतर हुआ करता था। यह न केवल रूबी पर लागू होता है, बल्कि अन्य भाषाओं और रूपरेखाओं पर भी लागू होता है। हर साल, सुरक्षा सुविधाओं को फ्रेमवर्क में अधिक से अधिक गहराई से एकीकृत किया जा रहा है। उदाहरण के लिए, रेल में पहले से ही हर जगह बॉक्स से बाहर सीएसआरएफ टोकन हैं, जो बहुत अच्छा है। और यह सब हुड के तहत काम करता है, लेकिन अगर आप नहीं जानते कि कैसे और कुछ कस्टम करना चाहते हैं, तो आवेदन की सुरक्षा से समझौता किया जा सकता है।

यदि हम कमजोरियों पर विचार करते हैं, तो उन्हें मोटे तौर पर 2 प्रकारों में विभाजित किया जा सकता है: ये रनटाइम में कमजोरियां हैं और भाषा की कमजोरियां हैं। एक बार पाइथन में एक दुखद कहानी थी - यह पता चला कि पायथन में डिक्शनरी के लिए हैश की गणना नमक के बिना की गई है। दुर्भावनापूर्ण रूप से कई टक्करों को भड़का सकता है। नतीजतन, शब्दकोश बह निकला, और सर्वरों पर हमला करने के अनुरोध के कई मेगाबाइट से मर गए। मुझे बताइए, आपके रेल की दुनिया में, आपके अनुभव में, रूबी में कितनी कमजोरियाँ हैं, और कितनी कमजोरियाँ हैं?

यदि हम कमजोरियों के विषय को देखते हैं, तो यह सिर्फ रूबी और रेल की तुलना में अधिक व्यापक है। उदाहरण के लिए, हमारे पास nginx है। यदि इसे सही तरीके से कॉन्फ़िगर नहीं किया गया है, तो आप बस सर्वर से कुछ फ़ाइलों को पढ़ सकते हैं और रेल एप्लिकेशन का रहस्य प्राप्त कर सकते हैं। और वह यह है, आवेदन हैक किया गया है - आप क्या चाहते हैं। आपको यह समझने की आवश्यकता है कि सुरक्षा केवल एक भाषा और ढांचे तक सीमित नहीं है - एक ऐसा वातावरण है जहां इसे निष्पादित किया जाता है, एक ऐसा वातावरण जहां इसे इकट्ठा किया जाता है, और एक मिलियन अलग-अलग बारीकियों।

और मात्रा के संदर्भ में, क्या आप किसी तरह पता लगा सकते हैं कि कहां अधिक कमजोरियां हैं? रूबी और रेल के बाहर, भाषा में ही, इसके रनटाइम में, मानक पुस्तकालय में, या रेल में एक रूपरेखा के रूप में जो रूबी का उपयोग करता है?

मैं कहूंगा कि अधिकांश भेद्यताएं तर्क और तर्क के बीच जंक्शन पर हैं या खुद को या पुस्तकालय के अन्य कार्यों के लिए।

पिछले कुछ वर्षों में, आपको या आपके सहयोगियों को सबसे मजेदार भेद्यता क्या मिली? श्रृंखला से "आह, ठीक है, कि तुम क्या करना था की तरह है।"

सबसे यादगार भेद्यता मणि में थी, जिससे आवाज ग्रंथों की अनुमति मिलती थी। आप उसे पाठ देते हैं, और वह उसे आवाज़ देता है। जेम ने कंसोल उपयोगिता कहा जाता है और उचित स्क्रीनिंग के बिना इसे मापदंडों को पारित कर दिया। नतीजतन, बैश में एक इंजेक्शन की खोज की गई थी, और आप एक मनमाना आदेश निष्पादित करने का परिणाम सुन सकते थे। आप इनपुट को कमांड "ls /" भेजते हैं, और प्रतिक्रिया में आवाज "स्लैश देव स्लैश आदि" और इतने पर निर्देशित करते हैं।

पिछले कुछ वर्षों में, सुपर-उच्च-स्तरीय भाषाओं के पारिस्थितिकी तंत्र - पायथन, रूबी, जावास्क्रिप्ट - ने बड़ी संख्या में छोटे पुस्तकालयों पर भरोसा किया है। उनमें से बहुत से हैं, और वे एक-दूसरे पर निर्भर हैं ताकि कुछ पैड-बायीं ओर निकल जाएं, और यह पारिस्थितिकी तंत्र को मारता है। हमलावर या तो अपनी लाइब्रेरी बनाना शुरू कर देते हैं, या अजनबियों पर नियंत्रण कर लेते हैं और उनमें कुछ दुर्भावनापूर्ण कोड जोड़ देते हैं, जो आपको नहीं मिल सकते। अब यह कितना बड़ा और भयानक है?

एक समस्या है, लेकिन अभी तक कोई भी वास्तव में इसके बारे में नहीं सोचता है, हर कोई "यादृच्छिक पर" निर्भर करता है। यदि किसी हमलावर का किसी विशिष्ट कंपनी पर एक निश्चित तरीके से हमला करने का लक्ष्य है, तो आज कोई भी उसे नहीं रोकेगा। कुछ भी नहीं बस एक अच्छा मणि बनाने से रोकता है, GitHub पर बहुत सारे सितारों को प्राप्त करना और सभी को इसका उपयोग शुरू करने की प्रतीक्षा करना। फिर, गुप्त रूप से इसमें दुर्भावनापूर्ण कोड एम्बेड करें, जो बिल्कुल भी मुश्किल नहीं है। मुझे लगता है कि आज निर्भरता का सवाल भरोसे का सवाल है: समस्या खुली है और अभी भी इसके समाधान की प्रतीक्षा कर रही है।

रूबिरसिया में मिलते हैं!

सुरक्षा के विषय पर सवाल रिपोर्ट के बाद मिखाइल से पूछे जा सकते हैं, साथ ही उनकी कंपनी के स्टैंड पर भी चर्चा की जा सकती है। आप देख सकते हैं कि 28 सितंबर को वेबसाइट पर रूबिस्ट किन अन्य विषयों पर चर्चा करेंगे।

और वक्ताओं और प्रतिभागियों के अलावा, आप सम्मेलन का समर्थन करने वाली अद्भुत कंपनियों से परिचित हो सकते हैं:

आयोजक - एवरोन
सामान्य साझेदार - शीर्षताल
गोल्ड पार्टनर - गेट
सिल्वर पार्टनर्स - वेलारम , जेटब्रेन , बुकमेट और कैशवगन
कांस्य भागीदार - InSales