सुरक्षित पायथन कोड कैसे लिखें। भोजन कुशल दास

यहाँ इस साक्षात्कार का मूल अंग्रेजी संस्करण है।

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

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



- मैंने खाया, कृपया हमें अपने बारे में और अजगर के साथ अपने काम के बारे में थोड़ा बताएं।

कुशाल दास: मैं भारत में रहता हूं, अब मैं प्रेस फाउंडेशन के अमेरिकी गैर-लाभकारी संगठन फ्रीडम, जहां मैं सिक्योरड्रॉप परियोजना का समर्थन करने में मदद करता हूं, में एक जनहित टेक्नोलॉजिस्ट के रूप में काम करता हूं। सिक्योरड्रॉप एक ओपन सोर्स इंफॉर्मेशन प्लेटफॉर्म है। यहां की मुख्य भाषा पायथन है।

इसके अलावा, मैं अन्य ओपन सोर्स प्रोजेक्ट्स में शामिल हूं, जिसमें पायथन भाषा भी शामिल है। मैं सीपीथॉन कोर डेवलपर्स में से एक हूं और पायथन सॉफ्टवेयर फाउंडेशन के निदेशक मंडल का सदस्य हूं।

मैं 2005 से पायथन के साथ काम कर रहा हूं, और लगभग मेरा पूरा करियर इस भाषा के साथ-साथ लिनक्स के साथ जुड़ा हुआ है। ये मेरे हितों के दो मुख्य क्षेत्र हैं। मैं तोर प्रोजेक्ट कोर टीम का सदस्य भी हूं। जैसा कि पहले से ही कई लोग जानते हैं कि टोर आपकी निजता को ऑनलाइन रखने में मदद करता है।

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

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

आपको क्या लगता है अभी भी बेहतर है: सुरक्षा लोगों को शिक्षित करना या उन्हें कुछ उपकरण प्रदान करना?

मैंने दास को खाया: मुझे लगता है कि वे दोनों। दरअसल, सुरक्षा एक जटिल मुद्दा है। हालांकि, अगर कोई नौसिखिया प्रोग्रामर बुनियादी प्रशिक्षण से गुजरता है या एक टीम के रूप में काम करता है, तो वह सबसे आम समस्याओं से बचने के लिए सीखता है।

ज्यादातर बार, वास्तविक सुरक्षा त्रुटियां, जैसे हैकिंग, डेटा रिसाव या डेटा चोरी, गलत कॉन्फ़िगरेशन, अपडेट की कमी या गलत, कभी-कभी गुंडे कोड के कारण उत्पन्न होती हैं।

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

एक बहुत ही सरल उदाहरण निर्भरता की जाँच है जो अब GitHub के पास है। यदि पायथन एप्लिकेशन में त्रुटियां हैं या एक स्वतंत्र मॉड्यूल के कुछ पुराने संस्करण का उपयोग करता है, और CVE में वर्णित एक निश्चित भेद्यता है, तो GitHub आपको एक डेवलपर के रूप में बता सकता है: "अरे! एक अद्यतन यहाँ आवश्यक है! ” - और बॉट स्वचालित रूप से मॉड्यूल को अपडेट करने के लिए पीआर करने की कोशिश करेगा।

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

- हाँ, दुर्भाग्य से, यह है। आधुनिक सॉफ्टवेयर विकास खुली रिपॉजिटरी पर बहुत निर्भर करता है जैसे कि पायथन पैकेज इंडेक्स, नोड.जेएस, एनपीएम, आदि। विकास के वर्तमान स्तर पर, यह आमतौर पर पाइप स्थापित या कविता जोड़ने के रूप में होता है ।

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

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

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

इसके अलावा, पाइप का उपयोग करके किसी भी पैकेज को स्थापित करते समय, आप वास्तव में इसकी जांच कर सकते हैं और सुनिश्चित कर सकते हैं कि यह वही है जो आपको चाहिए, साथ ही डाउनलोड की सुरक्षा की जांच करें। उदाहरण के लिए, PEP 458 है, जो आपको PyPI पैकेट हस्ताक्षर के साथ डाउनलोड की सुरक्षा करने की सलाह देता है।

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

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

— , , - , , , .

, , node.js npm, npm install something.

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

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

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

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

- धन्यवाद, मुझे उम्मीद है कि समय के साथ, लोग सुरक्षा के बारे में अधिक सोचेंगे और हमारे पारिस्थितिकी तंत्र में अधिक जांच का निर्माण करेंगे। मॉस्को पायथन कॉन्फ ++ में अपने आगामी प्रदर्शन के बारे में थोड़ा बात करते हैं । यह अंतर्निहित निर्भरता सुरक्षा और पैकेजिंग के आसपास बनाया गया है।

हम यहां खराब नहीं करेंगे, लेकिन सुरक्षा विशेषज्ञ के दृष्टिकोण से, आपके दृष्टिकोण से, आवेदन सुरक्षा की जांच करते समय डेवलपर्स को और क्या ध्यान रखना चाहिए?

हमने पहले ही चर्चा की है कि निर्भरता से निपटने और पैकेजों को कैसे सुरक्षित किया जाए। साधारण डेवलपर द्वारा और क्या जाँच की जानी चाहिए? मुझे क्या खोजना चाहिए?

मैंने दास को खाया: मुझे लगता है कि मुख्य बिंदुओं में से एक को अपडेट होना चाहिए। सुनिश्चित करें कि आपके पास कम से कम यह आदेश है, और आपके द्वारा निर्भर सब कुछ ओएस सहित अपडेट किया गया है, चाहे वह लिनक्स, मैक, विंडोज या यहां तक ​​कि आईओएस भी हो। वैकल्पिक रूप से, सुनिश्चित करें कि आप कम से कम मॉडल को समझने के लिए प्रक्रिया करें कि और क्या गलत हो सकता है।

ज्यादातर मामलों में शुरुआती (और मेरे साथ ऐसा हो चुका है) के लिए समस्या यह है कि हम उपयोगकर्ता इनपुट पर आँख बंद करके भरोसा करते हैं। आपको इस तथ्य पर कम भरोसा करने की आवश्यकता है कि इनपुट वास्तव में सही है और इससे कोई अन्य समस्या नहीं होगी। सब कुछ डबल-चेक किया जाना चाहिए।

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

एक प्रोग्रामिंग दृष्टिकोण से, मुझे लगता है कि ये दो मुख्य बिंदु हैं जो बहुत से लोग भूल जाते हैं।

- हां, ऐसी बहुत सी चीजें हैं जिनके बारे में लोग भूल जाते हैं, और अब, मुझे लगता है, आखिरी सवाल। आपके व्यक्तिगत अनुभव के आधार पर, पायथन मिड-लेवल बैकेंड डेवलपर्स किस तरह की सुरक्षा त्रुटियां करते हैं? उपयोगकर्ता का निवेश? व्यसनों? सुरक्षित अनुप्रयोग पैकेजिंग? क्या अधिक आम है?

ईटन दास: मैंने जो समस्याएं देखीं, वे मुख्य रूप से गलत प्रविष्टि के कारण थीं।

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

यह उसी विषय की एक निरंतरता है, जब आपको यह सुनिश्चित करने की आवश्यकता होती है कि यदि आप कुछ बनाते या खोलते हैं तो कोड "क्लीन अप" है। इसलिए यह मेरे लिए एक गंभीर सबक था। जब आप सोचते हैं, "हाँ, मैंने यह किया है! सब कुछ मेरे लैपटॉप पर काम करता है! ”, यह एक तथ्य नहीं है कि यह वास्तविक रिलीज़ या प्रोडक्शन में काम करेगा।

किसी कारण से, हम अक्सर सोचते हैं कि पर्यावरण हमारे स्थानीय के समान होगा, लेकिन ऐसा कभी नहीं होता है। यहां तक ​​कि बड़ी कंपनियों को अक्सर ग्राहक पक्ष पर वास्तविक वातावरण निर्धारित करना मुश्किल होता है। बस इसे ध्यान में रखना महत्वपूर्ण है।

और आगे -अपने कोड पर अधिक टिप्पणियां करें , प्रलेखन लिखें। यह टिप न केवल शुरुआती लोगों के लिए है, बल्कि अनुभवी डेवलपर्स के लिए भी है। यदि आपने कई महीनों या कई वर्षों तक कोड में नहीं देखा है, तो यह समझना बहुत मुश्किल हो सकता है कि आपने एक बार कुछ क्यों लिखा था।

कुशाल दास मॉस्को पायथन कॉन्फ ++ में प्रदर्शन करेंगे । हमें गिरावट के लिए एक बड़े ऑफ़लाइन सम्मेलन को स्थगित करने के लिए मजबूर किया गया था, लेकिन 27 मार्च को हमने एक मिनी-ऑनलाइन सम्मेलन आयोजित किया, जिसकी सामग्री हम जल्द ही साझा करेंगे, संपर्क में रहें।