रेल्स सुरक्षा के लिए सर्वोत्तम अभ्यास: एक व्यापक गाइड

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

रूबी ऑन रेल्स सुरक्षा के विवरण में गहराई से जाने से पहले, आइए थोड़ा रुककर अच्छे समय को याद करें।

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

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

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

आपका क्लाइंट आपकी ओर से आपके कोड को सुरक्षित नहीं बना सकता। आपका मैनेजर आपके लिए यह नहीं कर सकता। यह सब आप पर निर्भर करता है। इसलिए आप बेहतर जानते हों कि आप क्या कर रहे हैं।

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

• क्या आप सुरक्षा के लिए सर्वोत्तम अभ्यास का पालन करने की कोशिश करते हैं लेकिन उन्हें वास्तव में नहीं समझते?
• क्या आप इस बारे में अस्पष्ट हैं कि XSRF, MITM, और XSS हमले कैसे काम करते हैं?
• क्या आपको लगता है कि चूंकि आपके ऐप्स छोटे या आंतरिक हैं, इसलिए वे जोखिम में नहीं हैं?

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

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

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

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

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

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

बॉटनेट आपको गिरा देंगे

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

विदेशी सरकारें आपका पीछा कर रही हैं

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

क्या यह सुपर मजेदार काम नहीं लगता?

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

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

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

आवश्यक पठन

यह अपर्याप्त गाइड है। क्या आपने उम्मीद की थी कि यह व्यापक होगा? न्यूनतम आपको यह भी पढ़ना चाहिए:

• रेल्स सुरक्षा गाइड
• आधिकारिक रूबी सुरक्षा पृष्ठ

आठ रूबी सुरक्षा कमजोरियां (या प्व्न होने के आठ आसान तरीके)

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

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

• गैर-तकनीकी
• क्रॉस-साइट स्क्रिप्टिंग (XSS)
• क्रॉस-साइट रिक्वेस्ट फोर्जरी (CSRF, XSRF)
• मैन-इन-द-मिडिल (MITM)
• SQL इंजेक्शन (SQLI)
• मास असाइनमेंट और पैरामीटर इंजेक्शन
• डिनायल ऑफ सर्विस (DOS, DDOS)
• प्लेटफॉर्म हमले (आपके एप्लिकेशन को चलाने वाले होस्ट का शोषण)

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

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

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

न करें:

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

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

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

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

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

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

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

आप यह चाहते हैं।

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

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

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

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

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

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

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

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

क्रॉस-साइट रिक्वेस्ट फोर्जरी

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

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

रिक्वेस्ट फिर भी जाती है। हमलावर एक सावधानीपूर्वक शोषण के साथ इस तथ्य का लाभ उठा सकते हैं।

CSRF हमले की संरचना

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

और यह और भी बुरा है अगर आपका ऐप POST रिक्वेस्ट के बजाय GET रिक्वेस्ट का उपयोग कर रहा है।

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

सौभाग्य से, रूबी ऑन रेल्स ज्यादातर अंतर्निहित CSRF सुरक्षा प्रदान करके इस श्रेणी के हमले से बचाता है। आप इसे "वह अजीब टेक्स्ट जो किसी कारण से मेरे सभी फॉर्म में डाल दिया जाता है" के रूप में जानते होंगे।

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

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

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

बेशक, आप एक कंट्रोलर में कोड की एक प्रतीत होता है निर्दोष लाइन के साथ CSRF जांच को अक्षम कर सकते हैं:

skip_before_action :verify_authenticity_token

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

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

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

मैन-इन-द-मिडिल हमले और पैकेट स्निफिंग

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

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

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

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

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

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

SSL बचाव के लिए

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

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

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

SQL इंजेक्शन

इंटरनेट पर अधिकांश वेबसाइटें टेक्स्ट के टुकड़ों को जोड़कर 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") में, "amount" स्ट्रिंग को बिना एस्केप किए क्वेरी में जोड़ा जाता है?

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

यहां एक उदाहरण IRB सत्र है, जो sum मेथड में अविश्वसनीय इनपुट पास करने के परिणाम दिखाता है:

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 को, रूसी हैकर एगोर होमाकोव ने एक मास असाइनमेंट भेद्यता का खुलासा किया जो एक हमलावर को किसी भी गिटहब उपयोगकर्ता के रूप में सामने आने दे सकता था। जैसा कि आप कल्पना कर सकते हैं, यह असाधारण रूप से समस्याग्रस्त था।

गिटहब कैसे हैक हुआ

मैं शर्त लगाता हूं कि आपने इस तरह का कोड सैकड़ों बार लिखा है:

User.create(params[:user])

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

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

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

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

या गिटहब के मामले में, ऐसा कुछ:

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

मास असाइनमेंट एक आसान समाधान है

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

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

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

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

डिनायल ऑफ सर्विस हमले

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

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

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

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

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

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

यह बिल्कुल कूल लगता है, है ना?

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

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

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

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

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

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

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

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

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

अपनी रेल्स सुरक्षा को लेवल अप करने का समय

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

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

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