रेल सुरक्षा की सर्वोत्तम प्रथाओं के लिए एक व्यापक मार्गदर्शिका

<पी> यदि आप मेरे जैसे हैं, तो आप इस व्यवसाय में आये हैं क्योंकि आपको अद्भुत ऐप्स बनाना पसंद है। यदि आप काफी समय से विकास क्षेत्र में हैं, तो आपको अंततः उन अद्भुत ऐप्स पर काम करना होगा जो इतने अद्भुत नहीं लगते हैं . सुरक्षा उन चीजों में से एक हो सकती है। रेल सुरक्षा को गंभीरता से लेना महत्वपूर्ण है, भले ही रेल ढांचा भारी भार उठाने का काम करता हो।

<पी> इससे पहले कि हम रूबी ऑन रेल्स सुरक्षा के विवरण में गहराई से उतरें, आइए एक सेकंड के लिए अच्छे समय पर विचार करें।

<पी>

रेल सुरक्षा की सर्वोत्तम प्रथाओं के लिए एक व्यापक मार्गदर्शिका

<पी> ...और अब वास्तविक दुनिया में वापस।

<पी> यह बेकार है कि आपको सुरक्षा खतरों के बारे में भी चिंता करनी होगी। यह बहुत ही ख़राब बात है कि ऐसे लोग हैं जो हर सुबह उठते हैं और आपके द्वारा बनाई जा रही चीज़ों को तोड़ने की कोशिश करते हैं।

<पी> लेकिन ये लोग मौजूद हैं. वे आपकी सुरक्षा में छेद करने के लिए कड़ी मेहनत करते हैं। और जब वे सफल हो जाते हैं, तोयह आपकी गलती है। <पी> आपका ग्राहक आपकी ओर से आपके कोड को सुरक्षित नहीं बना सकता. आपका प्रबंधक आपके लिए यह नहीं कर सकता. यह सब आप पर है. तो आप बेहतर जानते हैं कि आप क्या कर रहे हैं।

आपको रेल सुरक्षा की परवाह क्यों करनी चाहिए?

क्या आप सुरक्षा के लिए सर्वोत्तम प्रथाओं का पालन करने का प्रयास करते हैं लेकिन वास्तव में उन्हें समझ नहीं पाते हैं?
क्या आप इस बारे में स्पष्ट नहीं हैं कि XSRF, MITM और XSR हमले कैसे काम करते हैं?
क्या आपको लगता है कि क्योंकि आपके ऐप्स छोटे या आंतरिक हैं, इसलिए उन्हें कोई ख़तरा नहीं है?

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

क्या आपको लगता है कि आपका एप्लिकेशन लक्ष्य नहीं है?

<पी> आप शायद ग़लत हैं यदि यह इंटरनेट पर है, तो यह घेरे में है। स्वचालित सिस्टम चौबीसों घंटे असुरक्षित वेब ऐप्स की स्कैनिंग कर रहे हैं।

<पी> चाहे संगठित अपराध हो या बॉट, इंटरनेट बुरे तत्वों से भरा पड़ा है जो आपके उपयोगकर्ताओं के डेटा पर अपना हाथ जमाना चाहते हैं।

संगठित अपराध एक वास्तविक है

<पी> क्या आप अपने डेटाबेस में क्रेडिट कार्ड संग्रहीत कर रहे हैं? अनसाल्टेड पासवर्ड हैश? मुझे आशा नहीं है! यदि हां, तो आप बर्बाद हो गए हैं। रेल्स इस तरह की गलतियों से बचना अपेक्षाकृत दर्द रहित बनाती है।

बॉटनेट आपको नीचे ले जाएगा

<पी>

<पी> जब आप बॉटनेट चलाते हैं, तो अधिक बॉट अधिक पैसे के बराबर होते हैं। तो आप एक एक्सप्लॉइट पैक खरीदें, इसे अपने मैलवेयर को इंस्टॉल करने के लिए सेट करें जब कोई पुराना ब्राउज़र पेलोड से टकराता है, और फिर कई उपयोगकर्ताओं को पेलोड वितरित करने के लिए कुछ वैध साइटों को हैक करें।

विदेशी सरकारें आपको पाने के लिए तैयार हैं

<पी> यह एक मजाक जैसा लगता है, लेकिन चीनी सरकार के पास हजारों लोग हैं जो व्यापार रहस्य, सरकारी खुफिया जानकारी और यहां तक कि राजनीतिक दुश्मनों के बारे में जानकारी की तलाश में सिस्टम को हैक कर रहे हैं।

<पी> क्या यह बहुत मज़ेदार काम नहीं लगता?

<पी>

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

हैक्टिविस्ट छाया में छुपे हुए हैं

<पी> क्या आप रक्षा विभाग को क्षीण यूरेनियम स्लग बेचते हैं? फिर, आपके पास किसी ऐसे व्यक्ति को नौकरी पर रखने के लिए पर्याप्त पैसा होना चाहिए जो जानता हो कि वे क्या कर रहे हैं। हैक्टिविस्ट नियमित रूप से उन वेबसाइटों को लक्षित करते हैं जो उनकी सक्रियता के लक्ष्य के अनुरूप होती हैं।

आवश्यक पढ़ना

<पी> यह अपर्याप्त मार्गदर्शिका है. क्या आपको उम्मीद थी कि यह व्यापक होगा? कम से कम आपको यह भी पढ़ना चाहिए:

रेल सुरक्षा मार्गदर्शिका
आधिकारिक रूबी सुरक्षा पृष्ठ

आठ रूबी सुरक्षा कमजोरियाँ (या p0wn'd पाने के आठ आसान तरीके)

<पी> अब जबकि हम इस बात पर सहमत हैं कि सुरक्षा कितनी गंभीर है (यहां तक कि छोटे ऐप्स के लिए भी), तो आप शायद सोच रहे होंगे कि यह कैसे सुनिश्चित किया जाए कि आपका रूबी ऐप सुरक्षित है।

<पी> हम कमजोरियों के आठ वर्गों को कवर करने जा रहे हैं जिसे वेब डेवलपर्स के लिए समझना महत्वपूर्ण है।

गैर-तकनीकी
क्रॉस-साइट स्क्रिप्टिंग (XSS)
क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ, एक्सएसआरएफ)
मैन इन द मिडिल (MITM)
एसक्यूएल इंजेक्शन (एसक्यूएलआई)
मास असाइनमेंट और पैरामीटर इंजेक्शन
सेवा से इनकार (DOS, DDOS)
प्लेटफ़ॉर्म हमले (आपके एप्लिकेशन को चलाने वाले होस्ट का शोषण करना)

गैर-तकनीकी सुरक्षा शोषण जो रूबी ऑन रेल्स सुरक्षा को प्रभावित कर सकते हैं

<पी> कभी-कभी, स्पष्ट समस्याओं को देखना सबसे कठिन होता है। हो सकता है कि आपको ये गलतियाँ किसी चेकलिस्ट पर न दिखें, लेकिन कुछ सामान्य ज्ञान का उपयोग करना उचित है।

<पी> आपके द्वारा की जा सकने वाली मूर्खतापूर्ण चीजों की संख्या और विविधता अनंत है, इसलिए हम केवल कुछ का उल्लेख करेंगे।

<पी> ऐसा न करें:

ईमेल के माध्यम से प्लेनटेक्स्ट पासवर्ड भेजें
हर जगह एक ही पासवर्ड का उपयोग करें
उन लोगों पर भरोसा करें जो कुकीज़ के साथ आपके कार्यालय में आते हैं
संवेदनशील डेटा अपने लैपटॉप पर रखें

क्रॉस-साइट स्क्रिप्टिंग

<पी> एक प्रकार की भेद्यता है जो एक दुर्भावनापूर्ण अभिनेता को आपके उपयोगकर्ताओं का फायदा उठाने देती है क्योंकि वे आपके एप्लिकेशन का उपयोग करते हैं।

<पी> यदि मैं एक बुरा अभिनेता हूं, तो मुझे आपके पेज में अपनी कुछ जावास्क्रिप्ट डालने के तरीकों में काफी दिलचस्पी हो सकती है।

<पी> एक बार जब मैं ऐसा कर लेता हूं, तो मैं सक्रिय सत्र कुकीज़ चुरा सकता हूं, एक एक्सप्लॉइट किट को DOM में बूटस्ट्रैप कर सकता हूं, या पेजों पर अजीब बातें भी कह सकता हूं। यह बहुत हानिकारक नहीं लग सकता है, लेकिन दुर्भावनापूर्ण सामग्री डालने से भी प्रतिष्ठा को नुकसान हो सकता है।

<पी>

क्रॉस-साइट स्क्रिप्टिंग से बचाव का एक आसान तरीका है

<पी> क्रॉस-साइट स्क्रिप्टिंग का लाभ उठाने की चाहत रखने वाले हमलावरों को विफल करने के लिए, आपको उपयोगकर्ता इनपुट से किसी भी टेक्स्ट से बचना होगा, ताकि जावास्क्रिप्ट हानिरहित टेक्स्ट में बदल जाए।

<पी> आप यह चाहते हैं.

&lt;script&gt;alert('I am stealing your cookies! Ha!');&lt;/script&gt;

<पी> आप यह नहीं चाहते:

<script>alert('I am stealing your cookies! Ha!');</script>

कभी-कभी क्रॉस-साइट स्क्रिप्टिंग से बचाव करना इतना आसान नहीं होता है

<पी> बात ये है. यदि आपके पास कोई पुराना रेल एप्लिकेशन बिना सुरक्षा पैच के चल रहा है, तो संभवतः आपके पास XSS कमजोरियाँ हैं। रेल के शुरुआती संस्करण में, आपको h() का उपयोग करके मैन्युअल रूप से अविश्वसनीय इनपुट से बचना होता था विधि.

<पी> आधुनिक रेल ऐप्स डिफ़ॉल्ट रूप से HTML आउटपुट से बचते हैं, जो अधिकांश XSS कमजोरियों को बॉक्स से बाहर होने से रोकता है। लेकिन इसे छोड़ना अब भी आश्चर्यजनक रूप से आसान है, खासकर जब विरासत कोड, तृतीय-पक्ष लाइब्रेरी, या गतिशील HTML रेंडरिंग से निपटते हैं।

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

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

क्रॉस-साइट अनुरोध जालसाजी

<पी> रेल अनुप्रयोगों में एक अन्य सामान्य सुरक्षा भेद्यता को क्रॉस-साइट अनुरोध जालसाजी कहा जाता है। आइए एक उदाहरण देखें।

<पी> यदि कोई उपयोगकर्ता अपना पासवर्ड बदलना चाहता है, तो वे बैकएंड पर एक फॉर्म पोस्ट करते हैं, है ना? तो, यदि फ़ॉर्म आपकी वेबसाइट पर नहीं है तो क्या होगा?

<पी> अनुरोध अभी भी जारी है. हमलावर सावधानीपूर्वक इस तथ्य का फायदा उठा सकते हैं।

सीएसआरएफ हमले की शारीरिक रचना

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

<पी> और यह और भी बुरा है यदि आपका ऐप POST अनुरोधों के बजाय GET अनुरोधों का उपयोग कर रहा है।

<पी> मुझे तुम्हें धोखा भी नहीं देना पड़ेगा। मैं आपके द्वारा हाल ही में देखे गए पृष्ठ पर एक छवि टैग जोड़कर एक प्रमाणित अनुरोध उत्पन्न कर सकता हूं।

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

<input type="hidden" name="authenticity_token" value="kM3jN8vBx2QzE-7wRtFpL6aYsI9uZcXmD4oHgK1rVnWe5qA0bUiJlSfTyP3hG2oC8xZ7mBvNkL4wQrEtYuI6pA" autocomplete="off" />

<पी> अस्पष्ट पाठ एक गुप्त कुंजी है जो उपयोगकर्ता के सत्र डेटा में संग्रहीत होती है। यदि उपयोगकर्ता एक सीएसआरएफ टोकन सबमिट करता है जो सत्र में मेल नहीं खाता है, तो आपका ऐप एक अपवाद फेंकता है। सौभाग्य से, हनीबेजर आपको इन अपवादों को ढूंढने और ठीक करने में मदद कर सकता है!

लेकिन आप अभी भी इसे खराब कर सकते हैं

<पी> बेशक, आप नियंत्रक में कोड की एक स्पष्ट रूप से निर्दोष पंक्ति के साथ सीएसआरएफ जांच को अक्षम कर सकते हैं:

skip_before_action :verify_authenticity_token

<पी> आप उन चीजों के लिए GET रूट का उपयोग करके भी समस्याएँ पैदा कर सकते हैं जो POST रूट होनी चाहिए:

MyApp::Application.routes.draw do
 match "/launch_all_the_missiles", to: "missiles#launch_all"
end

<पी> लेकिन आप ऐसा नहीं करेंगे, है ना? फिर भी, सीएसआरएफ के बारे में डरावनी बात यह है कि इसमें आपका ऐप होना जरूरी नहीं है जिसमें समस्या हो। एक उपयोगकर्ता सीएसआरएफ एक्सप्लॉइट एम्बेडेड के साथ किसी अन्य साइट पर जा सकता है, जिससे आपके ऐप के लिए अनुरोध ट्रिगर हो सकता है। रेल्स के जवाबी उपायों पर भरोसा करने से आपको इस तरह की चीज़ों से बचाव में मदद मिल सकती है।

आदमी-बीच में हमले और पैकेट सूँघना

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

<पी> एक हफ्ते बाद, लिफाफा विन्नी के घर पहुंचता है, जिसमें कोई नकदी नहीं होती। क्या हुआ? किसी ने आपके और इच्छित प्राप्तकर्ता के बीच लिफाफे की सामग्री के साथ छेड़छाड़ की है। यह एक साधारण मानव-मध्य आक्रमण है।

एप्लिकेशन कुकीज़ मैन-इन-द-मिडिल हमलों के प्रति संवेदनशील हैं

<पी> उपरोक्त कहानी थोड़ी मूर्खतापूर्ण लग सकती है, लेकिन आपके उपयोगकर्ताओं की कुकीज़ के साथ भी यही हो सकता है।

<पी> कुकीज़ आमतौर पर प्रत्येक वेब अनुरोध के साथ भेजी जाती हैं। यदि उन्हें सार्वजनिक (वाईफ़ाई) नेटवर्क पर स्पष्ट टेक्स्ट में भेजा जाता है, तो खेल ख़त्म हो गया है।

<पी> फायरशीप जैसा कुछ चलाने वाला कोई दुष्ट व्यक्ति आसानी से उपयोगकर्ता की कुकीज़ की प्रतियां प्राप्त कर सकता है और उनके खाते से समझौता कर सकता है।

बचाव के लिए एसएसएल

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

<पी> सुरक्षित कुकीज़ केवल HTTPS कनेक्शन पर ब्राउज़र पर भेजी जाएंगी, जो कि रेल 3 के बाद से डिफ़ॉल्ट है।

<पी> यदि आप इतने बदकिस्मत हैं कि रेल का इससे पुराना संस्करण चला रहे हैं, तो सुरक्षित कुकीज़ को सादे पाठ पर भेजा जा सकता है। इतना सुरक्षित नहीं है, हुह?

एसक्यूएल इंजेक्शन

<पी> इंटरनेट पर अधिकांश वेबसाइटें SQL नामक भाषा में छोटे प्रोग्राम बनाने के लिए टेक्स्ट के टुकड़ों को एक साथ जोड़कर काम करती हैं।

<पी> जरा उसके बारे में सोचो. क्या तुम्हें अंदाज़ा है कि यह कितना पागलपन है?

<पी> लेकिन, यह पसंद है या नहीं, चीजें इसी तरह काम करती हैं। और इस तथ्य के आधार पर कि इंटरनेट मौजूद है, इसे उचित रूप से अच्छी तरह से काम करना चाहिए।

<पी> इंटरनेट पर SQL को इधर-उधर घुमाने का एक दुष्परिणाम यह है कि यदि कोई हैकर छोटे SQL प्रोग्रामों में अपने स्वयं के पाठ के टुकड़े जोड़ सकता है, तो आपके डेटा में समस्याएँ आ सकती हैं।

<पी>

SQL इंजेक्शन का एक उदाहरण

<पी> कल्पना कीजिए कि आपका ठेकेदार आपको कुछ कोड भेजता है जो इस तरह दिखता है।

Building.where("st_intersects(st_setsrid(st_makebox2d(st_point(#{params[:northeast][:lng]}, #{params[:northeast][:lat]}), st_point(#{params[:southwest][:lng]}, %{params[:southwest][:lat]})), 4326), buildings.location)")

<पी> यह एक बहुत बड़ी गलती है जो आपको SQL इंजेक्शन तक पहुंचा सकती है। SQL क्वेरी में सीधे पैराम्स तक पहुंचने से क्लाइंट को अपने स्वयं के SQL को निष्पादित करने के लिए बाध्य करने का विकल्प मिलता है। एक चतुर हमलावर params[:southwest][:lat] बना सकता है इसमें इस तरह के कुछ दुर्भावनापूर्ण SQL कोड शामिल हैं:

")), 4326), buildings.location); UPDATE users SET admin=1 WHERE id=666;--"

<पी> और अब मेरी उपयोगकर्ता आईडी के पास व्यवस्थापकीय विशेषाधिकार हैं। SQL इंजेक्शन सामान्य और आसान कारनामे हैं, इसलिए जो कोई भी अपनी साइट के ट्रैफ़िक को लंबे समय तक देखता है, उसे अंततः SQL इंजेक्ट करने के कुछ प्रयास दिखाई देंगे।

रेल हमें SQL इंजेक्शन से लगभग स्वचालित रूप से बचाता है

<पी> रेल कई मामलों में SQL इंजेक्शन से बचाता है, जब तक आप ऐसा करने देते हैं। यदि हमने where का उपयोग किया होता सही ढंग से, पैरामीटर बच गए होते, और SQL इंजेक्शन प्रयास विफल हो गए होते।

where("st_intersects(st_setsrid(st_makebox2d(st_point(?, ?), st_point(?, ?)), 4326), #{table_name}.location)", box[:northeast][:lng], box[:northeast][:lat], box[:southwest][:lng], box[:southwest][:lat]).

रेल हमेशा SQL इंजेक्शन से सुरक्षा नहीं देती

<पी> लेकिन ऐसे बहुत से स्थान हैं जहां रेल्स कच्चे SQL का उपयोग करता है। वे स्थान जिन्हें आप आसानी से नज़रअंदाज कर सकते हैं।

<पी> उदाहरण के लिए, क्या आप जानते हैं कि SomeModel.sum("amount") में , "राशि" स्ट्रिंग को बिना एस्केप किए क्वेरी में जोड़ दिया जाता है?

<पी> इसलिए यदि आपके पास एक रिपोर्ट है जहां आप sum पर कॉल करते हैं params["col"] की सीधी पहुंच वाली विधि , आप मुसीबत में हैं।

<पी> यहां आईआरबी सत्र का एक उदाहरण दिया गया है, जो योग विधि में अविश्वसनीय इनपुट पास करने के परिणामों को दर्शाता है:

pry(main)> User.sum(%[id) AS sum_id FROM users; update users set
admin='t' where id=224;--])
(22.4ms) SELECT SUM(id) AS sum_id FROM users; update users set
admin='t' where id=224;--) AS sum_id FROM "users" 
=> "0"

<पी> #pluck के लिए भी यही सच है , साथ ही कई अन्य तरीके।

बड़े पैमाने पर असाइनमेंट हमले

<पी> 4 मार्च 2012 को, रूसी हैकर ईगोर होमाकोव ने एक बड़े पैमाने पर असाइनमेंट भेद्यता का खुलासा किया जो एक हमलावर को किसी भी GitHub उपयोगकर्ता के रूप में छिपाने की अनुमति दे सकता था। जैसा कि आप कल्पना कर सकते हैं, यह असाधारण रूप से समस्याग्रस्त था।

GitHub को कैसे हैक किया गया

<पी> मुझे यकीन है कि आपने इस तरह का कोड सैकड़ों बार लिखा होगा:

User.create(params[:user])

<पी> रूबी कोड की पठनीयता के लिए धन्यवाद, यह बताना बहुत आसान है कि यह कोड दिए गए मापदंडों के साथ एक उपयोगकर्ता बनाता है।

<पी> रेल 3.2.3 से पहले, इसका मतलब था कि कोई भी पैरामीटर वह इनपुट मॉडल को सौंपा जाएगा जब तक कि आपने स्पष्ट रूप से अन्यथा निर्दिष्ट न किया हो।

<पी> इससे जो समस्या पेश की गई वह यह थी कि इसे भूलना आसान था। और इसलिए आप खुद को एक ऐसी दुनिया में पाते हैं जहां एक हमलावर को ऐसा करने के लिए बस सही POST अनुरोध भेजना होता है:

User.create({admin: true, ...})

<पी> या GitHub के मामले में, कुछ इस तरह:

PublicKey.update({user_id: "123"})

बड़े पैमाने पर असाइनमेंट एक आसान समाधान है

<पी> आधुनिक रेल ऐप्स में बड़े पैमाने पर असाइनमेंट कमजोरियों का पसंदीदा समाधान स्ट्रॉन्ग पैरामीटर्स का उपयोग करना है, जिससे आपको इस लेख में पहले से परिचित होना चाहिए।

<पी> संपूर्ण params को आँख मूँद कर पारित करने के बजाय हैश से User.create , आप स्पष्ट रूप से घोषणा करते हैं कि किन विशेषताओं की अनुमति है:

def user_params
 params.require(:user).permit(:name, :email)
end

User.create(user_params)

<पी> यह सरल विकल्प केवल उन फ़ील्ड्स को सूचीबद्ध करके आपके मॉडल की सुरक्षा करता है जिन्हें आप अपडेट करना चाहते हैं। यह रेल्स 4 और उससे आगे की डिफ़ॉल्ट सुरक्षा है। यदि आप वास्तव में कोई पुराना ऐप (जैसे रेल्स 4 या पुराना) बनाए रख रहे हैं, तो यह अपग्रेड करने लायक है।

सेवा हमलों से इनकार

<पी> आज तुमने कितने लोगों को परेशान किया है? पिछले महीने के बारे में क्या?

<पी> डिनायल ऑफ सर्विस अटैक (डीओएस) और डिस्ट्रीब्यूटेड डिनायल ऑफ सर्विस अटैक (डीडीओएस) इन्फोसेक समुदाय के रेज कॉमिक के संस्करण हैं। ये हमले आपका डेटा चुराने या मैलवेयर फैलाने वाले नहीं हैं। वे बस आपको बंद करना चाहते हैं। इससे अभी भी आपकी कंपनी को भारी वित्तीय या प्रतिष्ठा क्षति हो सकती है।

DDOS एक कच्चा लेकिन प्रभावी हमला है

<पी> सेवा से इनकार करने वाले हमले को शुरू करने के लिए, बस अपने 500 सबसे करीबी दोस्तों को फोन करें, उन्हें एमनेस्टी इंटरनेशनल की वेबसाइट पर जाने के लिए कहें, और एक घंटे के लिए रिफ्रेश दबाते रहें। बॉट्स को मित्रों के स्थान पर प्रतिस्थापित किया जा सकता है

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

एल्गोरिदमिक जटिलता हमले

<पी> यह बहुत बढ़िया लगता है, है ना?

<पी> ये हमले आपके ऑपरेटिंग सिस्टम, एप्लिकेशन स्टैक इत्यादि में एक विशेष कमजोरी का फायदा उठाते हैं, जिससे एप्लिकेशन होस्ट पर समस्याएं पैदा होती हैं। उनका उपयोग आपके सर्वर की मेमोरी को भरने, आपके सीपीयू उपयोग को बढ़ाने या यहां तक कि डिस्क स्थान को भरने के लिए किया जा सकता है।

<पी> उदाहरण के लिए, क्लासिक SYN बाढ़ हमला एक सर्वर पर SYN अनुरोध भेजकर काम करता है। सर्वर ढेर सारे कनेक्शन खोलता है जो बंद नहीं हैं। पर्याप्त खुले कनेक्शन के साथ, ऑपरेटिंग सिस्टम की मेमोरी जल्दी खत्म हो जाएगी, और एप्लिकेशन स्वयं क्रैश हो जाएगा। यह एक सार्थक समस्या उत्पन्न करने के लिए एल्गोरिथम वास्तविकता का शोषण करता है जो किसी एप्लिकेशन को पूरी तरह से हटा सकता है।

पुराने जमाने का अच्छा सर्वर शोषण करता है

<पी> जब हम हैकर्स के बारे में सोचते हैं तो वास्तव में हम यही सोचते हैं, है ना? संदिग्ध लोग बफर ओवरफ़्लो का उपयोग करके अपाचे को रूट उपयोगकर्ता के रूप में मनमाना कोड चलाने के लिए प्रेरित करते हैं?

<पी> लेकिन कई उबाऊ कामों की तरह, इसे भी स्वचालित कर दिया गया है। यदि आप अभी अपने सिस्टम लॉग को देखते हैं, तो मुझे यकीन है कि आप बॉट्स को SSH लॉगिन को बलपूर्वक करने का प्रयास करते हुए देखेंगे।

हमले का पता लगाने को स्वचालित करें

<पी> आप उन होस्ट के आईपी पते को स्वचालित रूप से ब्लॉक करने के लिए फेल2बैन जैसे लोकप्रिय टूल का उपयोग कर सकते हैं जो आपके खिलाफ ज्ञात हमलों का प्रयास कर रहे हैं।

वह चीज़ें करें जिनके बारे में आप जानते हैं कि आपको करना चाहिए।

<पी> अपने ऑपरेटिंग सिस्टम को दुरुस्त रखें. ऐसी सेवाएँ न चलाएँ जिनकी आपको आवश्यकता नहीं है। SSH के लिए पासवर्ड प्रमाणीकरण की अनुमति न दें. सूची चलती रहती है. यदि आप किसी प्लेटफ़ॉर्म का उपयोग करते हैं, तो इसका अधिकांश भाग आपके लिए प्रबंधित किया जाता है।

यह आपकी रेल सुरक्षा को उन्नत करने का समय है

<पी> सबसे पहले, घबराओ मत! रेल सुरक्षा आपके काम का हिस्सा है, चाहे आप इसे पसंद करें या नहीं। अब जब आप इसे गंभीरता से ले रहे हैं, तो आप कमजोरियों को कम करने में त्वरित प्रगति करेंगे। एक कम लेकिन प्रभावी जीत यह सुनिश्चित करना है कि आप रेल के उस संस्करण का उपयोग कर रहे हैं जो अभी भी सुरक्षा अद्यतन प्राप्त कर रहा है। यदि फ़्रेमवर्क ऐसे संस्करण पर चल रहा है जिसने वर्तमान में महत्वपूर्ण कमजोरियाँ प्रकाशित की हैं, तो दुनिया में मौजूद सभी SQL आपकी सुरक्षा नहीं कर सकते। यही बात आपकी रत्न निर्भरता के लिए भी लागू होती है।

<पी> एक बार फ्रेमवर्क समर्थित हो जाने पर, अपने ऐप के जोखिम के सतह क्षेत्र को कम करने के लिए इस गाइड (और रेल सुरक्षा गाइड!) का उपयोग करें। मजबूत मापदंडों का प्रयोग करें. एक दर सीमक और शायद एक प्रॉक्सी कॉन्फ़िगर करें। तरीकों के लिए HTTP सम्मेलनों का पालन करें और ट्रैफ़िक को SSL होने के लिए बाध्य करें। ये सभी चीजें धीरे-धीरे इस संभावना को कम कर देंगी कि आपको सुरक्षा समस्या का सामना करना पड़ेगा।

<पी> संपादक का नोट:यह पोस्ट मूल रूप से मार्च 2013 में प्रकाशित हुई थी और सटीकता के लिए इसे अपडेट किया गया है।