मैं रुबी में रक्षात्मक रूप से प्रोग्राम कैसे कर सकता हूं?

Question

यहां समस्या का एक आदर्श उदाहरण है: Classifier gem breaks Rails।

** मूल प्रश्न: **

एक बात है कि मुझे एक सुरक्षा पेशेवर के रूप में चिंताओं कि रूबी जावा के पैकेज-गोपनीयता की एक समानांतर नहीं है। यही कारण है, यह वैध रूबी नहीं है:

public module Foo 
    public module Bar 
    # factory method for new Bar implementations 
    def self.new(...) 
     SimpleBarImplementation.new(...) 
    end 
    def baz 
     raise NotImplementedError.new('Implementing Classes MUST redefine #baz') 
    end 
    end 

    private class SimpleBarImplementation 
    include Bar 
    def baz 
     ... 
    end 
    end 
end 

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

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

(और नहीं, कोर कक्षाएं रूबी में डिफ़ॉल्ट रूप से जमे हुए नहीं कर रहे हैं नीचे देखें :)

require 'md5' 
# => true 
MD5.frozen? 
# => false 

Answer 1

गैरी डॉली द्वारा Immutable देखें।

आप व्यक्तिगत तरीकों के पुनर्वितरण को रोक सकते हैं।

Answer 2

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

Answer 3

मुझे नहीं लगता कि यह एक चिंता है।

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

ठेठ चिंताओं में से एक है:

require 'awesome' 
# Do something awesome. 

लेकिन क्या किसी को इतना है कि यह का उपयोग करता है:

require 'evil_cracker_lib_from_russian_pr0n_site' 
# Overrides crypto functions and sends all data to mafia 
require 'awesome' 
# Now everything is insecure because awesome lib uses 
# cracker lib instead of builtin 

मैं इस भयानक पुस्तकालय है, जो इतनी तरह इस्तेमाल किया जा माना जाता है लिख रहा हूँ

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

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

Answer 4

जावा रक्षात्मक प्रोग्रामिंग के लिए अन्य उपकरणों के बहुत सारे प्रदान करता है

शुरू में मैंने सोचा था कि आप के बारे में normal defensive programming, जिसमें विचार कार्यक्रम की रक्षा के लिए है (या इसके अपने सबसेट, या अपने एकल समारोह बात कर रहे थे) अमान्य डेटा इनपुट से।
यह एक अच्छी बात है, और मैं सभी को उस लेख को पढ़ने के लिए प्रोत्साहित करता हूं।

हालांकि ऐसा लगता है कि आप वास्तव में "अन्य प्रोग्रामर से अपने कोड का बचाव" के बारे में बात कर रहे हैं।

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

यदि आप केवल अक्षम सह-श्रमिकों से अपने कोड की रक्षा करने की मांग कर रहे हैं, तो यह हास्यास्पद है। अपने सहकर्मियों को शिक्षित करें, या बेहतर सहकर्मियों को प्राप्त करें।

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

Answer 5

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

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

require 'evil_cracker_lib_from_russian_pr0n_site' 
require 'awesome' 

मैं awesome की आवश्यकता होती है foobar और fazbot, और foobarhas_gumption की आवश्यकता होती है के बारे में चिंतित हूँ, और ... अंत में कुछ अस्पष्ट तरीके से इन संघर्ष के दो कि नाश कर देती है:

मैं इस बारे में चिंतित नहीं हूँ एक महत्वपूर्ण सुरक्षा पहलू।

एक महत्वपूर्ण सुरक्षा सिद्धांत "गहराई में रक्षा" है - सुरक्षा की इन अतिरिक्त परतों को जोड़ने से आपको गलती से पैर में खुद को शूटिंग करने में मदद मिलती है। वे इसे पूरी तरह से रोक नहीं सकते हैं; नहीं कर सकता। लेकिन वे मदद करते हैं।

Answer 6

यदि बंदर पैचिंग आपकी सहमति है, तो आप अपरिवर्तनीय मॉड्यूल (या समान कार्य में से एक) का उपयोग कर सकते हैं।

Immutable

Answer 7

आप क्यों लकी कड़ी के "सैंडबॉक्स" परियोजना, यदि आप के बारे में संभावित चिंता असुरक्षित कोड चल उपयोग कर सकते हैं, जिस पर एक बार देख ले सकता है। http://code.whytheluckystiff.net/sandbox/

एक उदाहरण (ऑनलाइन TicTacToe): किसी एक वस्तु या एक मॉड्यूल monkeypatched http://www.elctech.com/blog/safely-exposing-your-app-to-a-ruby-sandbox

Answer 8

है, तो आप 2 मामलों में देखने की जरूरत है: वह एक नई पद्धति गयी। यदि वह अकेला है जो इस मेहोड को जोड़ता है (जो बहुत संभावना है), तो कोई समस्या नहीं आती है। यदि वह एकमात्र नहीं है, तो आपको यह देखने की ज़रूरत है कि दोनों विधियां समान हैं या इस गंभीर समस्या के बारे में लाइब्रेरी डेवलपर को बताएं।

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

इसके अलावा, आप इस धारणा के साथ एक बहुत ही गतिशील भाषा का उपयोग कर रहे हैं कि प्रोग्रामर इस स्वतंत्रता को एक तरह से उपयोग करते हैं। इस धारणा को हटाने का एकमात्र तरीका गतिशील भाषा का उपयोग नहीं करना है।

Answer 9

रागनवाल्ड के बारे में recent post है। अंत में उन्होंने निम्नलिखित बनाता है:

class Module 
    def anonymous_module(&block) 
    self.send :include, Module.new(&block) 
    end 
end 

class Acronym 
    anonymous_module do 
    fu = lambda { 'fu' } 
    bar = lambda { 'bar' } 
    define_method :fubar do 
     fu.call + bar.call 
    end 
    end 
end 

कि fubar को उजागर करता है Acronym रों पर एक सार्वजनिक विधि के रूप में, लेकिन आंतरिक हिम्मत (fu और bar) निजी रहता है और बाहर देखने से सहायक मॉड्यूल छुपाता है।