2012-02-20 16 views
8

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

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

मैं इस तरह से गुप्त बचत कर रहा हूँ:

encryptor = ActiveSupport::MessageEncryptor.new(Example::Application.config.secret_token) 
cookies[:secret] = { 
    :value => encryptor.encrypt(secret), 
    :domain => "example.com", 
    :secure => !(Rails.env.test? || Rails.env.development?) 
} 

और फिर मैं इसे इस तरह पढ़ रहा हूँ:

encryptor = ActiveSupport::MessageEncryptor.new(Example::Application.config.secret_token) 
secret = encryptor.decrypt(cookies[:secret]) 

कि सुरक्षित है? ऐसा करने के किसी भी बेहतर तरीके?

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

+0

ब्याज से, इसे सर्वर-पक्ष की बजाय कुकी में संग्रहीत करने की आवश्यकता क्यों है, जहां यह परिभाषा अधिक सुरक्षित होगी? – Russell

+0

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

+0

मैंने एक जवाब जोड़ा है क्योंकि मुझे लगता है कि डीबी का उपयोग करने के लिए डिफ़ॉल्ट सत्र स्टोर को बदलना आपको टेबल बनाने के संबंध में बहुत कम ओवरहेड के साथ सुरक्षा प्रदान करेगा। – Russell

उत्तर

0

मैं JacobM के उत्तर को दोबारा पोस्ट कर रहा हूं, कि उसने हटा दिया, क्योंकि यह सही जवाब था और मुझे सही दिशा में इंगित किया। अगर वह इसे हटा देता है, तो मैं इसे हटा दूंगा और उसे सर्वश्रेष्ठ जवाब के रूप में चुनूंगा।

सबसे पहले, यदि आप encrypt_and_verifyencrypt के बजाय का उपयोग यह कुकी आप के लिए हस्ताक्षर करेंगे।

हालांकि, जब सुरक्षा की बात आती है, तो मैं हमेशा समाधानों पर भरोसा करना पसंद करता हूं जो सार्वजनिक रूप से स्वयं को घुमाने के बजाय सार्वजनिक रूप से पेश किए जाते हैं। एक उदाहरण encrypted-cookies gem होगा।

+0

मुझे उत्सुकता है कि आप हस्ताक्षरित कुकीज़ का उपयोग क्यों नहीं करेंगे? (रेल 3.x में डिफ़ॉल्ट रूप से समर्थित) –

+1

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

+0

यह समझ में आता है .. –

13
  • एक सुरक्षित कुकी

    cookies.signed[:secret] = { 
    :value => "foo bar", 
    :domain => "example.com", 
    :secure => !(Rails.env.test? || Rails.env.development?) 
    } 
    
  • कुकी

    cookies.signed[:secret] # returns "foo bar" 
    

कुकी ActionController::Base.cookie_verifier_secret का उपयोग करके हस्ताक्षरित है पहुँचना स्थापना। आप प्रारंभकर्ता फ़ाइल में cookie_verifier_secret सेट कर सकते हैं।

+0

मैं सत्र का उपयोग नहीं करना चाहता हूं। मेरे सत्र प्रति डोमेन (blah.example.com) हैं जबकि डेटा का यह टुकड़ा पूरे सिस्टम (.example.com) के लिए है, इसलिए इसे सेट करते समय डोमेन विकल्प। – Pablo

+0

उत्तर अपडेट किया गया एक नज़र डालें। –

+0

.signed के साथ सेट की गई कुकीज़ को भी साइन इन करने की आवश्यकता है। तो आपका दूसरा कोड ब्लॉक 'कुकीज़.signed [: गुप्त] होना चाहिए। –

1

कंदडाबोगू कहते हैं, ऐसा लगता है कि आप एक सत्र चर क्या चाहते हैं, और सत्र चर डिफ़ॉल्ट रूप से एन्क्रिप्टेड और कुकीज़ में संग्रहीत हैं। हालांकि, अगर आप config/initializers/session_store.rb की सामग्री पर एक नजर है आप की तरह कुछ मिल जाएगा निम्नलिखित:

# Be sure to restart your server when you modify this file. 
MyRailsApp::Application.config.session_store :cookie_store, :key => '_my_rails_app_session' 

# Use the database for sessions instead of the cookie-based default, 
# which shouldn't be used to store highly confidential information 
# (create the session table with "rails generate session_migration") 
# MyRailsApp::Application.config.session_store :active_record_store 

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

+0

मैं सत्र का उपयोग नहीं करना चाहता हूं। मेरे सत्र प्रति डोमेन (blah.example.com) हैं जबकि डेटा का यह टुकड़ा पूरे सिस्टम (.example.com) के लिए है, इसलिए इसे सेट करते समय डोमेन विकल्प। – Pablo