अन्य संभावित रूप से हानिकारक सुविधाओं के विपरीत, बुराई जैसी सुविधाओं को बुराई क्यों माना जाता है?

Question

अधिकांश आधुनिक भाषाओं (जो किसी तरह व्याख्या की जाती हैं) में किसी प्रकार का निष्कासन कार्य होता है। ऐसा फ़ंक्शन मनमाने भाषा कोड को निष्पादित करता है, ज्यादातर समय मुख्य तर्क के रूप में एक स्ट्रिंग के रूप में पारित किया जाता है (विभिन्न भाषाएं eval फ़ंक्शन में अधिक सुविधाएँ जोड़ सकती हैं)।

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

• सॉफ्टवेयर तत्वों के लिए कस्टम एक्सेस नियम (IIRC OpenERP में एक ऑब्जेक्ट है ir.ruleजो डायनेमिक पायथन कोड का उपयोग कर सकता है)।
• कस्टम गणना और / या मानदंड (OpenERP में फ़ील्ड की तरह कस्टम कोड गणना की अनुमति है)।
• OpenERP रिपोर्ट पार्सर (हां मुझे पता है कि मैं आपको OpenERP सामान के साथ बाहर निकाल रहा हूं ... लेकिन यह मेरे पास मुख्य उदाहरण है)।
• कुछ आरपीजी खेल में कोडिंग वर्तनी प्रभाव।

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

हालांकि, लोकप्रिय संस्कृति में बुराई बुराई है। आपके सिस्टम में तोड़-फोड़ करने जैसी बातें दिमाग में आती हैं।

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

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

लेकिन evalफ़ंक्शंस (भाषा की परवाह किए बिना) के साथ कुछ खास है ।

प्रश्न : क्या इस डर के लिए कोई भी ऐतिहासिक तथ्य लोकप्रिय संस्कृति का हिस्सा बन गया है, बजाय संभवतः अन्य खतरनाक विशेषताओं पर ध्यान देने के लिए?

Comments

मैं असहमत हूं कि यह बहुत व्यापक है, और सबूत के रूप में मैं चार उत्तर प्रस्तुत करता हूं जो एक उचित लंबाई के हैं।

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

— पूछूंगा

यह अन्य खतरनाक विशेषताओं की तुलना में अधिक ध्यान देने के साथ लोकप्रिय संस्कृति का हिस्सा क्यों बन जाता है? क्योंकि अनुप्रास का निष्कासन - बुराई को याद रखना आसान है

— बर्गी

मेमोरी आवंटन और सूचक अंकगणित को कई लोगों द्वारा बुराई के रूप में देखा जाता है।

— user253751

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

— आंद्रे परमेस

Answer 1

एक evalफ़ंक्शन अपने आप में बुराई नहीं है, और एक सूक्ष्म बिंदु है जो मुझे विश्वास नहीं है कि आप बना रहे हैं:

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

मैंने कोड लिखा है जो एक evalप्रकार के फ़ंक्शन का उपयोग करता है और यह सुरक्षित था: कार्यक्रम और पैरामीटर हार्ड-कोड किए गए थे। कभी-कभी, कोई भी भाषा या पुस्तकालय की सुविधा नहीं होती है कि कार्यक्रम को क्या करना चाहिए और शेल कमांड चलाना छोटा रास्ता है। "मुझे इसे कुछ घंटों में कोड करना है, लेकिन जावा / .NET / PHP / जो भी कोड लिखने में दो दिन लगेंगे। या मैं evalइसे पांच मिनट में कर सकता हूं ।"

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

क्या इस डर के लिए कोई भी ऐतिहासिक तथ्य लोकप्रिय संस्कृति का हिस्सा बन गया है, बजाय इसके कि संभवतः अन्य खतरनाक विशेषताओं पर ध्यान दिया जाए?

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

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

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

Comments

आप एक हैं :)। यद्यपि यदि एक अच्छा प्रसिद्ध उदाहरण है जिसने इस संस्कृति में योगदान दिया है, तो मैं इसे उत्तर में देखना चाहूंगा।

— लुइस मूसली

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

मेरा आईडीई एक प्रोग्राम है जो मुझे अनुमति देता है - यह उपयोगकर्ता है - मनमाना इनपुट निष्पादित करने के लिए। मुझे यह खराब होने के बजाय उपयोगी लगता है।

— डेन

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

@ जेन: यह रेमंड चेन ने "एयरलॉक के दूसरे पक्ष" के रूप में संक्षेप में प्रस्तुत किया है। आप पहले से ही चला सकते हैं rm -rf /, आईडीई के माध्यम से जटिल तरीके से ऐसा करने की कोई आवश्यकता नहीं है। इसके साथ समस्या evalयह है कि यह बहुत सारे अभिनेताओं के लिए उस क्षमता को खोलता है जिनके पास वह क्षमता नहीं है।

— MSalters

Answer 2

इसका एक हिस्सा यह है कि बारीकियां कठिन हैं। यह कहना आसान है जैसे कि गोटो, सार्वजनिक क्षेत्र, एसक्यूएल प्रश्नों के लिए स्ट्रिंग प्रक्षेप, या निष्कासन का उपयोग न करें। इन कथनों को वास्तव में यह नहीं समझा जाना चाहिए कि किसी भी परिस्थिति में, उन्हें इस्तेमाल करने का कोई कारण नहीं है। लेकिन अंगूठे के एक सामान्य नियम के रूप में उनसे बचना अच्छा विचार है।

Eval को बहुत हतोत्साहित किया जाता है क्योंकि यह कई सामान्य मुद्दों को जोड़ती है।

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

दूसरे, शुरुआती बुरी तरह से संरचित कोड प्राप्त करने के लिए eval का उपयोग करते हैं। एक शुरुआती कोडर ऐसा कोड लिख सकता है जो दिखता है:

x0 = "hello"
x1 = "world"
x2 = "how"
x3 = "are"
x4 = "you?"
for index in range(5):
   print eval("x" + index)

यह काम करता है, लेकिन वास्तव में इस समस्या को हल करने का गलत तरीका है। जाहिर है, एक सूची का उपयोग करना बेहतर होगा।

तीसरा, eval आमतौर पर अक्षम है। हमारी प्रोग्रामिंग भाषा कार्यान्वयन में तेजी लाने के लिए बहुत प्रयास किया जाता है। लेकिन तेजी से गति बढ़ाना मुश्किल है और इसके इस्तेमाल से आमतौर पर आपके प्रदर्शन पर हानिकारक प्रभाव पड़ेगा।

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

Comments

आपका दूसरा मामला बहुत महत्वपूर्ण है। भाषाओं है कि में eval लेकिन यह भी संकलित कर रहे हैं, एक स्ट्रिंग एक चर संदर्भ का उत्पादन करने का मूल्यांकन गैर तुच्छ है। उदाहरण के लिए, यदि संकलित किया गयाvar x = 3; print(x) है , तो किसी भी रन-टाइम ज्ञान की आवश्यकता नहीं है कि स्रोत ने "x" नाम का उपयोग किया है। काम करने के लिए उस मैपिंग को रिकॉर्ड करना होगा। यह एक वास्तविक मुद्दा है: आम लिस्प में एक अनबाउंड वैरिएबल अपवाद को फेंक देगा क्योंकि लेक्सिकल वेरिएबल x का कोड संकलित होने के बाद नाम के साथ कोई संबंध नहीं है । var x = 3; print(eval("x"))(let ((x 3)) (print (eval 'x)))

— जोशुआ टेलर

@ जॉनहुआटेयोर का मतलब है तीसरा कारण, दूसरा नहीं?

— user253751

@ मिनीबिस, मुझे लगता है कि वह दूसरे कारण में कोड का उल्लेख कर रहा है। लेकिन आप सही हैं, इसका वास्तव में तीसरे कारण से संबंधित है: प्रदर्शन।

— विंस्टन इवर्ट

यह सवाल देखा , क्या तुम नहीं? ;)

— jpmc26

@ jpmc26, नहीं। लेकिन मैंने इसे बहुत देखा है।

— विंस्टन इर्वर्ट

Answer 3

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

"अन्य संभावित रूप से हानिकारक कीड़े" की सीमाएं अच्छी तरह से हो सकती हैं, जिसका अर्थ है कि वे परिभाषा के अनुसार, एक मनमाने कोड निष्पादन से कम नुकसान पहुंचाने में सक्षम हैं, जिसका शोषण किया जाता है।

Comments

तर्क के लिए, पॉइंटर्स का दुरुपयोग भी मनमाने ढंग से कोड निष्पादन के लिए होता है , फिर भी पॉइंटर्स की तुलना evalमें बहुत कम पर फेंक दिया जाता है।

— दिमित्री ग्रिगोरीव

@DmitryGrigoryev क्या वे वास्तव में हैं? C ++ से बाहर, पॉइंटर्स को आमतौर पर बेहद खतरनाक और टाला जाता है। उदाहरण के लिए, C # पॉइंटर्स का समर्थन करता है, लेकिन यह आपके द्वारा अन्य सभी विकल्पों (आमतौर पर डेटा हेरफेर पर प्रदर्शन कारणों के लिए) को समाप्त करने के बाद आपके द्वारा कोशिश की जाने वाली अंतिम चीज़ है। अधिकांश आधुनिक भाषाओं में संकेत के लिए कोई समर्थन नहीं है। यहां तक ​​कि C ++ खुद भी "सुरक्षित" पॉइंटर्स की ओर बढ़ रहा है, जो मनमाने ढंग से पॉइंटर्स के साथ समस्याओं को कम करने की कोशिश करते हैं (जैसे कि सिर्फ पॉइंटर्स के बजाय ट्रू लिस्ट / सरणियों का उपयोग करके safe_ptr, रेफरेंस पासिंग ...)।

— लुआॅन

@DmitryGrigoryev: क्या आप किसी के लिए एक संदर्भ प्रदान करते हुए कह सकते हैं कि संकेत स्पष्ट से कम खतरनाक हैं?

— जैक्सबी

@JacquesB यहाँ आप :)

— दिमित्री ग्रिगोरीव

@ जैक्सबी, हां; यह एक मजाक के रूप में था (मुझे उम्मीद थी कि मुस्कान इसे पर्याप्त स्पष्ट कर देगी)। ओपी ने वह बयान दिया, मुझसे नहीं, इसलिए आपको उनसे सबूत मांगना चाहिए।

— दिमित्री ग्रिगोरीव

Answer 4

एक व्यावहारिक और एक सैद्धांतिक कारण है।

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

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

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

Comments

बेशक, रनटाइम कोड पीढ़ी सही ढंग से किया जा सकता है, और eval उपयोगी हो सकता है। उदाहरण के लिए, मैं अक्सर मेटाप्रोग्रामिंग / मैक्रो-जैसे सामान के लिए eval का उपयोग करता हूं, खासकर जब मैं "क्लीनर" OOP या कार्यात्मक समाधान प्रदान कर सकता हूं। परिणामी कोड अक्सर बेहतर और सरल होता है क्योंकि इसमें बॉयलरप्लेट कम होता है। हालाँकि, सैंडबॉक्सिंग, एस्केपिंग मैकेनिज्म, कोड इंजेक्शन, स्कोपिंग रूल्स, एरर रिपोर्टिंग, ऑप्टिमाइज़ेशन आदि के बारे में विभिन्न समस्याओं से अवगत होने के लिए भाषा में एक उच्च स्तर की प्रवीणता की आवश्यकता होती है, और इस ज्ञान के बिना eval सकारात्मक रूप से खतरनाक है।

— अमोन

Answer 5

नहीं, कोई स्पष्ट ऐतिहासिक तथ्य नहीं है।

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

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

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

Comments

... या किसी विश्वसनीय स्रोत से आने वाला इनपुट है, जैसे कि गेम के लिए स्पेल डेफिनिशन फाइल।

— user253751

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

— जूल्स

@immibis - क्योंकि कोई भी कभी भी गेम फ़ाइलों को हैक नहीं करता है ...

— Telastyn

... यह "ट्यूरिंग पूर्ण" का अर्थ नहीं है (ट्यूरिंग पूर्णता अप्रासंगिक से वास्तविक दुनिया कंप्यूटिंग के लिए एक कदम दूर है)।

— लेउशेंको

@Telastyn: जो एक जावास्क्रिप्ट प्रोग्राम नहीं कर सकता है। या यहां तक ​​कि एक सी ++ प्रोग्राम। जावास्क्रिप्ट एक सैंडबॉक्स (ब्राउज़र) के अंदर चलता है जो स्वयं एक अन्य सैंडबॉक्स में है (रिंग 3 एक्स 86 में बोलते हैं)। ओएस कंट्रोल के तहत इंटरप्ट वेक्टर उस सैंडबॉक्स के बाहर होता है। और वह बाहरी सैंडबॉक्स, रिंग 3, सीपीयू-एनफोर्समेंट है।

— एमएसलर्स

Answer 6

मुझे लगता है कि यह निम्नलिखित पहलुओं को उबालता है:

• ज़रूरत
• (संरक्षित) उपयोग
• पहुंच
• verifiability
• मल्टी-स्टेज हमले

ज़रूरत

नमस्ते वहाँ, मैं यह बहुत अच्छा छवि संपादन उपकरण ($ 0.02 के लिए उपलब्ध है) लिखा है। आपके द्वारा छवि खोले जाने के बाद, आप अपनी छवि पर कई फिल्टर फ़िल्टर कर सकते हैं। तुम भी कुछ अपने आप को पायथन का उपयोग करके स्क्रिप्ट कर सकते हैं (जिस प्रोग्राम में मैंने एप्लिकेशन लिखा है)। मैं सिर्फ evalआपके इनपुट पर उपयोग करूंगा , आप एक सम्मानित उपयोगकर्ता होने के लिए विश्वास करते हैं।

(बाद में)

इसे खरीदने के लिए धन्यवाद। जैसा कि आपने वादा किया था कि आप इसे देख सकते हैं। ओह, आप एक छवि खोलना चाहते हैं? नहीं, आप नहीं कर सकते। मैं readविधि का उपयोग नहीं करूंगा क्योंकि यह कुछ असुरक्षित है। सहेजा जा रहा है? नहीं, मैं उपयोग नहीं करूंगा write।

मैं जो कहना चाह रहा हूं वह यह है: आपको लगभग बुनियादी उपकरणों के लिए पढ़ने / लिखने की आवश्यकता है। अपने ओह-इतने भयानक खेल के उच्च स्कोर के भंडारण के लिए भी।

पढ़ने / लिखने के बिना, आपका छवि संपादक बेकार है। बिना eval? मैं आपको उसके लिए एक कस्टम प्लगइन लिखूंगा!

(संरक्षित) उपयोग

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

हालाँकि, अन्य मामलों में, readप्रोग्रामर नियंत्रण (शायद हार्डकोड?) के लिए स्ट्रिंग पूरी तरह से नियंत्रण में है। उस मामले में, यह उपयोग करने के लिए शायद ही बुराई है read।

पहुंच

अब, एक और सरल उदाहरण, का उपयोग कर eval।

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

(यही है, जब तक आप उस अच्छे व्यवस्थापक को निकाल नहीं देते, लेकिन उसकी पहुंच को रद्द करना भूल जाते हैं। अब आपका वेब-ऐप ट्रैश हो गया है)।

Verifiability।

एक अन्य पहलू जो महत्वपूर्ण है, मुझे लगता है, उपयोगकर्ता इनपुट को सत्यापित करना कितना आसान है।

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

एक लेखन कॉल पर उपयोगकर्ता इनपुट? वही!

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

Eval? आप उस इनपुट को कैसे सत्यापित करेंगे जो evalकॉल के लिए उपयोग किया जाता है ? आप बहुत मेहनत कर सकते हैं, लेकिन यह वास्तव में कठिन है (यदि असंभव नहीं है) यह सुरक्षित रूप से काम करने के लिए।

मल्टी-स्टेज हमले

अब, हर बार जब आप उपयोगकर्ता इनपुट का उपयोग करते हैं, तो आपको खतरों के खिलाफ, इसका उपयोग करने के लाभों को तौलना होगा। जितना हो सके इसके उपयोग को सुरक्षित रखें।

evalव्यवस्थापक उदाहरण में सक्षम सामान पर फिर से विचार करें । मैंने तुमसे कहा था कि ठीक था।

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

(XSS के बजाय SQL इंजेक्शन के साथ एक ही मल्टी-स्टेज हमला किया जा सकता है, या कुछ मनमानी फ़ाइल उपयोग करने के बजाय निष्पादन योग्य कोड को बदल देती है eval)

Comments

"आप बहुत कठिन काम कर सकते हैं, लेकिन यह वास्तव में कठिन है (यदि असंभव नहीं है) यह सुरक्षित रूप से काम करने के लिए।" - यह है असंभव। सरल सबूत: यह पता लगाने की कोशिश करने के बजाय कि प्रदान किया गया कोड "सुरक्षित" है या नहीं, बस कुछ जानने की कोशिश करें, बहुत सरल, और देखें कि पहले से कितना कठिन है : क्या उपयोगकर्ता द्वारा प्रदान किया गया कोड रुक गया है?

— जोर्ग डब्ल्यू मित्तग

@ JörgWMittag: मुझे Coq में लिखा गया एक प्रोग्राम दें और मैं इसे साबित करूँगा।

— एंड्रे परमेस

@ JörgWMittag: सहमत। भाषा, और उपयोगकर्ता इनपुट के दायरे पर निर्भर करता है। यह भी हो सकता है eval("hard coded string" + user_input_which_should_be_alphanumeric + "remainder")। सत्यापित करना कि इनपुट अल्फ़ान्यूमेरिक है संभव है। इसके अलावा, onal क्या यह रुकता है ’यह access क्या यह स्पर्श नहीं करना चाहिए’ को संशोधित करता है / पहुंच स्थिति को संशोधित करता है और not क्या यह कॉल नहीं करना चाहिए ’को शांत करता है।

— सोज़ेरड जॉब पोस्टम्यूस

@ JörgWMittag यह साबित करना असंभव है कि किसी दिए गए कार्यक्रम में कुछ नहीं होगा , लेकिन यह असंभव नहीं है कि आप उन कार्यक्रमों के प्रतिबंधित सेट को रूढ़िवादी रूप से परिभाषित कर सकें जिनके लिए आप इसे साबित कर सकते हैं, और इनपुट कार्यक्रमों को लागू करने के लिए उस सेट के सदस्य हैं।

— user253751

Answer 7

इस सुविधा के लिए काम करने के लिए, इसका मतलब है कि मुझे एक प्रतिबिंब परत रखने की आवश्यकता है जो पूरे कार्यक्रम की आंतरिक स्थिति तक पूर्ण पहुंच सक्षम करती है।

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

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

इस तरह के कोड में बहुत सारे सूक्ष्म होते हैं, कीड़े को पुन: पेश करने के लिए कठिन होता है, और साथ ही यह जेआईटी संकलक में अनुकूलन पर एक सीमा भी रखता है।

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

Comments

"इस सुविधा के लिए काम करने के लिए, इसका मतलब है कि मुझे एक प्रतिबिंब परत रखने की आवश्यकता है जो पूरे कार्यक्रम की आंतरिक स्थिति तक पूर्ण पहुंच सक्षम करती है" - नहीं, सिर्फ उन हिस्सों पर जो आप प्रभावित करना चाहते हैं। OpenERP / Odoo के मामले में, निकाले जा रहे कोड की केवल बहुत ही सीमित संख्या में चर और कार्यों तक पहुंच होती है, जिसे वे कॉल कर सकते हैं, और वे सभी थ्रेड-लोकल हैं।

— एंड्रे परमेस

Answer 8

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

लेकिन जावास्क्रिप्ट द्वारा समर्थित सरल कारण के लिए evalएक अधिक प्रसिद्ध भेद्यता हो सकती है । जावास्क्रिप्ट प्रत्यक्ष स्मृति या फ़ाइल सिस्टम एक्सेस के बिना एक सैंडबॉक्स वाली भाषा है, इसलिए यह भाषा कार्यान्वयन में कमजोरियों को छोड़कर बस इन कमजोरियों को नहीं रखता है। Evalइसलिए यह भाषा की सबसे खतरनाक विशेषताओं में से एक है, क्योंकि यह मनमाने कोड निष्पादन की संभावना को खोलती है। मेरा मानना ​​है कि C / C ++ की तुलना में जावास्क्रिप्ट में कई और डेवलपर्स विकसित होते हैं, इसलिए evalडेवलपर्स के बहुमत के लिए बफर ओवरफ्लो की तुलना में जागरूक होना अधिक महत्वपूर्ण है।

Answer 9

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

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

Comments

इससे पूछे गए प्रश्न को संबोधित करने का प्रयास भी नहीं किया जाता है, "क्या इस भय का कोई लोकप्रिय तथ्य लोकप्रिय संस्कृति का हिस्सा है"। देखें कैसे जवाब दें

— gnat

मेरे विचार में यह प्रश्न एक झूठे आधार पर आधारित है, इसलिए मैंने इसका उत्तर इस प्रकार दिया।

— user1751825

Answer 10

मुझे लगता है कि आप इसे अपने प्रश्न (जोर मेरा) के निम्नलिखित भाग में अच्छी तरह से कवर करते हैं:

उनका एक अच्छा उपयोग है, जब तक वे ठीक से उपयोग किए जाते हैं

95% के लिए जो इसे ठीक से उपयोग कर सकता है वह सब अच्छी तरह से और अच्छा है; लेकिन हमेशा ऐसे लोग होंगे जो इसका सही इस्तेमाल नहीं करते हैं। उनमें से कुछ अनुभवहीनता और क्षमता की कमी के लिए नीचे होंगे, बाकी दुर्भावनापूर्ण होंगे।

हमेशा ऐसे लोग होंगे जो सीमाओं को धक्का देना चाहते हैं और सुरक्षा छेद ढूंढना चाहते हैं - कुछ अच्छे के लिए, कुछ बुरे के लिए।

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

जूमला! उदाहरण एक सरल हो सकता है, लेकिन यह एक ऐसा है जिसे रिकॉर्ड किया गया है।

Answer 11

के उपयोग को हतोत्साहित करने के लिए कुछ अच्छे कारण हैं eval(हालाँकि कुछ विशेष भाषाओं के लिए विशिष्ट हैं)।

• पर्यावरण (लेक्सिकली और डायनेमिक रूप से) का उपयोग evalअक्सर आश्चर्यचकित करता है (यानी, आपको लगता है कि eval(something here)एक काम करना चाहिए, लेकिन यह एक और करता है, संभवतः अपवादों को ट्रिगर करता है)
• अक्सर एक ही चीज़ को पूरा करने का एक बेहतर तरीका है (निर्माण किए गए लेक्सिकल क्लोजर का संक्षेपण कभी-कभी एक बेहतर समाधान होता है, लेकिन यह आम लिस्प-विशिष्ट हो सकता है)
• असुरक्षित डेटा का मूल्यांकन किया जाना बहुत आसान है (हालाँकि यह ज्यादातर इसके खिलाफ हो सकता है)।

मैं, व्यक्तिगत रूप से, यह कहते हुए दूर नहीं जाऊंगा कि यह बुराई है, लेकिन मैं हमेशा evalएक कोड समीक्षा के उपयोग को चुनौती दूंगा , "क्या आपने यहां कुछ कोड पर विचार किया है ?" (अगर मेरे पास कम से कम एक अस्थायी प्रतिस्थापन करने का समय है), या "क्या आपको यकीन है कि एक स्पष्ट वास्तव में यहां सबसे अच्छा समाधान है?" (अगर मैं नहीं)

Comments

इससे पूछे गए प्रश्न को संबोधित करने का प्रयास भी नहीं किया जाता है, "क्या इस भय का कोई लोकप्रिय तथ्य लोकप्रिय संस्कृति का हिस्सा है"। उत्तर कैसे

— gnat

Answer 12

मिंस्की की सोसाइटी ऑफ माइंड , अध्याय 6.4 में, वे कहते हैं

मन में खुद को देखने का एक तरीका है और फिर भी जो हो रहा है, उस पर नज़र रखें। मस्तिष्क को दो भागों में विभाजित करें, ए और बी वास्तविक दुनिया से ए-मस्तिष्क के इनपुट और आउटपुट को कनेक्ट करते हैं - इसलिए यह समझ सकता है कि वहां क्या होता है। लेकिन बी-ब्रेन को बाहरी दुनिया से बिल्कुल भी न जोड़ें; इसके बजाय इसे कनेक्ट करें ताकि ए-दिमाग बी-ब्रेन की दुनिया हो!

जब कोई प्रोग्राम (B) ​​कोई अन्य प्रोग्राम (A) लिखता है तो यह मेटा-प्रोग्राम के रूप में कार्य करता है। B का विषय पदार्थ प्रोग्राम A है।

सी कार्यक्रम है। वह आपके सिर में है जो प्रोग्राम बी लिखता है।

खतरा यह है कि कोई व्यक्ति (सी ') बुरी नीयत से हो सकता है, जो इस प्रक्रिया में हस्तक्षेप कर सकता है, इसलिए आपको एसक्यूएल-इंजेक्शन जैसी चीजें मिलती हैं।

चुनौती यह है कि सॉफ्टवेयर को और अधिक खतरनाक बनाये बिना उसे और अधिक खतरनाक बना दिया जाए।

Comments

दो अपवोट, और दो डाउनवोट। लगता है शायद यह एक तंत्रिका को हिट करता है।

— माइक डनलैवी

Answer 13

आपके पास यहां बहुत सारे अच्छे उत्तर हैं और मुख्य कारण स्पष्ट रूप से है कि मनमाने ढंग से कोड निष्पादन बुरा एमएमएमके है, लेकिन मैं एक अन्य कारक जोड़ूंगा जो दूसरों ने केवल किनारे पर छुआ है:

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