वेब सुरक्षा परीक्षण स्टार्टर किट

सभी को नमस्कार!

मेरा नाम एंड्री है। 10 वर्षों से मैं विभिन्न वेब सेवाओं में कमजोरियों को खोज रहा हूं। और मेरे ज्ञान को आपके साथ साझा करने के लिए तैयार है। पिछले मई में, मैंने हाइजेनबग सम्मेलन में इस बारे में एक रिपोर्ट बनाई थी, और अब मैं यहां अपना ज्ञान साझा करने के लिए तैयार हूं, वह भी, हैबर के खुले स्थानों में। तो चलिए शुरू करते हैं।

एक बार मैंने कुख्यात कंपनी फेसबुक के सर्वरों पर एक भेद्यता पाई । लोग ImageMagick (छवि प्रसंस्करण के लिए पुस्तकालय) और इसके लिए भुगतान करना भूल गए :) इस उदाहरण के साथ मैं यह दिखाना चाहता था कि हम सभी लोग हैं और हम सभी गलतियाँ कर सकते हैं, कोई फर्क नहीं पड़ता कि किन कंपनियों में और किन पदों पर हम काम करते हैं। एकमात्र समस्या यह है कि इन त्रुटियों से सभी प्रकार के जोखिम हो सकते हैं।
आपका एप्लिकेशन / वेबसाइट / टूल जितना अधिक जटिल होगा, उतनी ही अधिक संभावना है कि कुछ गलत हो सकता है।
आपको कमजोरियों की जांच करने की आवश्यकता है। ऐसा न करना मूर्खता है।

निम्नलिखित आइटम वेब अनुप्रयोगों की जाँच के चरण हो सकते हैं:

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

मैं इस सब के बारे में विस्तार से बात करूंगा।

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

XSS

XSS (क्रॉस-साइट स्क्रिप्टिंग) एक उपयोगकर्ता पर एक हमला है जो एक हमलावर को अपने शिकार के ब्राउज़र के संदर्भ में एक मनमाना स्क्रिप्ट निष्पादित करने की अनुमति देता है। सबसे अधिक बार, इसका तात्पर्य HTML टैग और JS स्क्रिप्ट के कार्यान्वयन से है।
उदाहरण: एक समय में ऐसी सेवा याहू थी! विज्ञापन विनिमय पासवर्ड रिकवरी फॉर्म में " रिटर्न यूआरएल " पैरामीटर था। यह संकेत दे सकता है कि पासवर्ड रीसेट प्रक्रिया के बाद किस पेज पर लौटना है। यदि आप एक या एक और वेक्टर वहां डालते हैं जो जेएस कोड के निष्पादन की ओर जाता है, तो आप सभी उपयोगकर्ता कुकीज़ प्राप्त कर सकते हैं । हम विश्लेषण करेंगे कि यह कैसे होता है और क्यों होता है।


यहाँ वेक्टर ही है। सभी एक बार में:

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

हम देखते हैं कि returnURL = / login.jsp
यह <इनपुट> टैग के मूल्य में आता है।
अगर हम jsp के बाद एक उद्धरण चिह्न जोड़ते हैं, तो हम देखेंगे कि HTML सिंटैक्स ने डाला है। सौभाग्य से, HTML भाषा सख्त नहीं है, पार्सर छोड़ देगा और कोई समस्या नहीं होगी:

एक और चरित्र जोड़ें। यहां हम <इनपुट> टैग के संदर्भ से पूरी तरह से बाहर हैं:

अब हम <svg> टैग के उद्घाटन को जोड़ते हैं, और हमें सिंटैक्स के संदर्भ में दो वैध टैग मिलते हैं:

अगला, संपूर्ण आक्रमण वेक्टर जोड़ें:

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


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

• संदर्भ से बाहर। ये 6 वर्ण न केवल HTML पैरामीटर मान के संदर्भ से बाहर निकलने में मदद करेंगे, बल्कि कई अन्य लोगों से भी:
  -> ''>
  

ठीक है, वास्तव में, दो सबसे सरल हमला वैक्टर:

• विशेष रूप से लिंक डालें। लेकिन सामान्य मामले में - पृष्ठ की उपस्थिति को बदलना। उदाहरण के लिए, वे आपके पृष्ठ में html कोड एम्बेड कर सकते हैं और डेटा के लिए कुछ नकली विंडो प्रदर्शित कर सकते हैं:
  
  String " aaaa " google.com की ओर इशारा करती है । आप देख सकते हैं कि लिंक पृष्ठ पर प्रस्तुत है, लेकिन आप इसे नहीं देख सकते हैं, लेकिन यह कोड में इसकी उपस्थिति को रद्द नहीं करता है। दोनों मामलों में, मामले को पूरा माना जा सकता है;
• स्क्रिप्ट निष्पादन, उदाहरण के लिए, उपयोगकर्ता कुकीज़ को रोकना:
  
  

XSS की खोज कहाँ और कैसे करें?

सबसे पहले, पृष्ठ पर जानकारी / डेटा आउटपुट फ़ंक्शन ढूंढें। विश्लेषण करें कि वहां क्या डेटा मिलता है? यहाँ एक अविश्वसनीय स्रोत की अवधारणा आती है। और इस तरह, सबसे पहले, आपका उपयोगकर्ता है । अटैक वैक्टर किसी भी अन्य स्रोतों में निहित हो सकते हैं: आरएसएस फ़ीड, अन्य सेवाएं, बाहरी और आंतरिक दोनों।
यहाँ एक वास्तविक जीवन उदाहरण है: मैं SEMrush IT के लिए काम करता हूँ। हम एक ऑनलाइन प्लेटफ़ॉर्म विकसित कर रहे हैं, जो ऑनलाइन मार्केटर्स के लिए एक सार्वभौमिक उपकरण है। इसलिए, एक सेवा ने डेटा को बचाया, दूसरे को कम किया, प्रत्येक टीम ने एक-दूसरे पर भरोसा किया, यह निकला कि दूसरी सेवा पर XSS उत्पन्न हुआ जो आउटपुट डेटा के उचित प्रसंस्करण की कमी के कारण उत्पन्न हुआ, और पहले कमांड ने आने वाले डेटा को फ़िल्टर करने के लिए आवश्यक नहीं माना। किसी भी तरह से और उन्हें " जैसा है " रखा। निष्कर्ष: यदि आप नहीं जानते कि यह या वह डेटा कैसे संग्रहीत किया जाता है, तो उन्हें अविश्वसनीय माना जाना चाहिए। या कौन स्टोर करता है और कैसे करता है, इसके बारे में पहले से सहमत हैं, डेटा प्रदर्शित करता है।

यदि आपके पास पहले से ही अविश्वसनीय स्रोतों से डेटा है, तो मैं सुझाव देता हूं:

• आने वाले डेटा के फ़िल्टरिंग का अध्ययन करने के लिए;
• आउटपुट के संदर्भ की जांच करें। सभी मामलों में एक्सएसएस को निष्पादित नहीं किया जा सकता है, यहां तक ​​कि फ़िल्टरिंग की अनुपस्थिति में भी। उदाहरण के लिए, यदि प्रतिक्रिया का सामग्री-प्रकार है: पाठ / सादा;
• एम्बेडेड सिक्योरिटी सिस्टम फ्रेमवर्क को फ़िल्टर करने पर भरोसा न करें।

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

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

उदाहरण (जीवन से नहीं, बल्कि अच्छे से भी):
हम एक स्क्रिप्ट देखते हैं जो एक उपयोगकर्ता तालिका प्रदर्शित करती है। इस मामले में, वह उपयोगकर्ता नाम से खोज सकता है।
दाईं ओर दिखाया गया है कि डेटाबेस में क्वेरी कैसे दिखती है, और बाईं ओर ब्राउज़र में स्क्रिप्ट का परिणाम है।

इसके अलावा, परीक्षण करने और कम से कम कुछ प्राथमिक परिणाम प्राप्त करने के लिए, हम नाम पैरामीटर के मान में दो उद्धरण सम्मिलित करते हैं। सिंगल और डबल:

हम देखते हैं कि आउटपुट के दृष्टिकोण से, सब कुछ अलग हो गया, तालिका पूरी तरह से गायब हो गई। अनुरोध को अतिरिक्त 2 उद्धरण चिह्न भी मिलते हैं। SQL क्वेरी का पूरा सिंटैक्स उल्लंघन किया जाता है।
यदि हम पैरामीटर वैल्यू में इस तरह के निर्माण को लेते हैं और जोड़ते हैं ( एड।: पीले बॉक्स में देखें ), तो हमें एक बिल्कुल वैध अनुरोध मिलता है। पृष्ठ आउटपुट पहले अनुरोध के समान है, जिसमें एक इंजेक्शन शामिल नहीं है:

पूरी तरह से यह सत्यापित करने के लिए कि एक भेद्यता है, हम एकता के बजाय एक ड्यूस जोड़ते हैं:

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

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

यह कुछ ऐसा है जिसे आप पैरामीटर में दर्ज करने का प्रयास कर सकते हैं, और फिर, उत्तरों में अंतर के अनुसार, यह समझने की कोशिश करें कि क्या हो रहा है, एक भेद्यता है या नहीं। लगभग 80% मामलों में आप इस हेरफेर के साथ कवर कर सकते हैं।
20% कठिन परिस्थितियां बनी हुई हैं, जिसमें यह आपको कोई जानकारी नहीं देगा, उदाहरण के लिए: नेस्टेड क्वेरी / फ़िल्टरिंग और इसी तरह। अपने अभ्यास में, मैं केवल एक बार एक समान से मिला। फिर मुझे सर्विस साइड पर फ़िल्टरिंग को बायपास करना पड़ा।

SQL में क्या है खतरा?

• स्पष्ट - सूचना रिसाव से । यदि कोई हमलावर आपके डेटाबेस में प्रश्न उत्पन्न करने में सक्षम था, तो वह एक तरह से या किसी अन्य मान को प्राप्त कर सकता है जो आउटपुट (पासवर्ड हैश, क्लाइंट एड्रेस, आदि) नहीं थे;
• डेटा परिवर्तन । अब कई डेवलपर्स ORM सिस्टम के माध्यम से डेटाबेस का उपयोग करते हैं। ये सिस्टम स्वयं, डिफ़ॉल्ट रूप से, आपको एक बार में कई प्रश्न करने की अनुमति देता है, SQL सिंटैक्स आपको यह करने की अनुमति भी देता है। यदि कोई भेद्यता है, तो सब कुछ न केवल डेटा के चयन में बदल सकता है, बल्कि उनके परिवर्तन (तालिकाओं को हटाने, डेटाबेस की संरचना को बदलने, आदि) तक भी बदल सकता है।
  उसी स्थिति में, उपयोगकर्ता विशेषाधिकारों में वृद्धि संभव है। फ़ील्ड को कुछ तालिकाओं में बदलें (उदाहरण के लिए, उपयोगकर्ताओं के डेटाबेस में is_admins = true डालें) और इस प्रकार आपके अधिकारों को व्यवस्थापक तक बढ़ा सकते हैं;
• DoS । कुछ मामलों में, एक इंजेक्शन सेवा से वंचित कर सकता है। डेटाबेस के लिए कई भारी क्वेरीज़ उत्पन्न होती हैं, कई थ्रेड्स में लॉन्च की जाती हैं, और आपकी सेवा कुछ समय के लिए काम करना बंद कर सकती है;
• सिस्टम फ़ाइलों को पढ़ना एक और आपदा है जो SQL इंजेक्शन ला सकता है। इस जोखिम की घटना इस बात पर निर्भर करती है कि आप किस डेटाबेस सिस्टम का उपयोग करते हैं, साथ ही जिस पर उपयोगकर्ता इसके साथ काम करता है (विशेषाधिकार प्राप्त है या नहीं);
• RCE (दूरस्थ कोड निष्पादन) कोड निष्पादन है। यह सीधे उपयोग किए जाने वाले डेटाबेस के प्रकार पर निर्भर करता है (पहले यह डिफ़ॉल्ट रूप से संभव था, डिफ़ॉल्ट डेटाबेस सेटिंग्स के साथ, MSSQL में)।

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

SSRF (सर्वर साइड अनुरोध क्षमा)

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

एक हमलावर है, आपका सर्वर है, जो फ़ायरवॉल द्वारा बंद है, लेकिन एक ही समय में एक कार्यक्षमता है जो आपको आगे सर्वर की ओर से अनुरोध करने की अनुमति देता है।
यदि यह कार्यक्षमता ठीक से संरक्षित नहीं है और / या गलत तरीके से, जैसा कि आमतौर पर होता है :), आने वाले डेटा को संसाधित करता है, तो हमलावर मेमकाटेड , रेडिस में बदल सकता है या पीड़ित के किसी भी आंतरिक संसाधनों तक पहुंच प्राप्त कर सकता है।

एक और अधिक उदाहरण के लिए, आंतरिक कर्मचारी प्रशिक्षण के लिए SEMrush का उपयोग करने वाले स्टैंड पर विचार करें।
" अवतार URL " के अर्थ पर ध्यान देना महत्वपूर्ण है:

यहां हम 2 बिंदुओं पर ध्यान देते हैं:

• अवतार यूआरएल ही
• और एक फ़ाइल का उपयोग करके इसे डाउनलोड करने की क्षमता।

कृपया ध्यान दें कि " अवतार URL " फ़ील्ड इनपुट के लिए एक पाठ क्षेत्र है, जिसका अर्थ है कि हम इस मूल्य में हेरफेर कर सकते हैं। आइए अवतार पर लगाने की कोशिश करें, शायद, इंटरनेट पर सबसे प्रसिद्ध चित्र - 404 त्रुटि पृष्ठ से Googlebot।
इसे एक बार करें:

दो - क्लिक करें " सहेजें ।" मुझे अपनी फोटो के बदले एक रोबोट मिलेगा:

यहां यह इस तथ्य पर ध्यान देने योग्य है कि " अवतार URL " का मूल्य कुछ स्थानीय पथ में बदल गया है - जाहिर है, आवेदन ने एक तस्वीर का अनुरोध किया, इसे सर्वर पर सहेजा और एक नया मूल्य प्रतिस्थापित किया।

हम आगे बढ़ते हैं। " URL अवतार " फ़ील्ड में, मान फ़ाइल दर्ज करें : /// etc / passwd । यह डिज़ाइन आपको फ़ाइल संरचना तक पहुंचने की अनुमति देता है। कुछ पुस्तकालयों में जो HTTP के साथ काम करने के लिए उपयोग करते हैं, डिफ़ॉल्ट रूप से, फ़ाइल संरचना के साथ काम चालू होता है और उन सर्वरों से डेटा प्राप्त करता है जिस पर वे लॉन्च किए गए थे:

" सहेजें " बटन पर क्लिक करने के बाद क्या होता है?
सबसे पहले, तस्वीर " बैट " बन गई, और दूसरी बात, फ़ाइल का मार्ग बदल गया।

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

इस प्रकार, इस भेद्यता की मदद से, मैं, एक हमलावर के रूप में, आपकी सेवा के सभी स्रोत कोड और वेब सेवा चलाने वाले उपयोगकर्ता को पढ़ने के लिए उपलब्ध अन्य डेटा प्राप्त कर सकता हूं।
आइए SSRF के खतरों को देखें:

• पोर्ट स्कैन। बाहरी नेटवर्क के लिए, आपकी सेवा एक प्रविष्टि बिंदु और 2 बंदरगाह (http और https) है। अपने बुनियादी ढांचे के अंदर से बंदरगाहों को स्कैन करके, एक हमलावर खुले बंदरगाहों का पता लगा सकता है;
• बायपास होस्ट-आधारित प्रमाणीकरण। क्या कहना है? यह संभव है कि आपकी संरचना के भीतर ऐसी सेवाएँ हैं जो केवल कुछ संसाधनों के लिए उपलब्ध हैं (पढ़ें: आईपी श्वेतसूची)। इसलिए, यदि आपका कमजोर सर्वर सफेद सूची में है, तो आपको उन सेवाओं तक पहुंच मिलती है जो उसके लिए उपलब्ध हैं, और, परिणामस्वरूप, आप उन्हें हेरफेर कर सकते हैं;
• उपरोक्त हमले के विकास को जारी रखते हुए, आप इंट्रानेट या स्थानीय सर्वर पर चल रहे कमजोर कार्यक्रमों का फायदा उठा सकते हैं। अक्सर ऐसी परिस्थितियां होती हैं जब आंतरिक बुनियादी ढांचा, बाहर से दुर्गम, खराब निगरानी की जाती है (संस्करण / सुरक्षा पैच, आदि हमेशा अपडेट नहीं होते हैं)। इससे हमले और डेटा चोरी भी हो सकती है;
• स्थानीय डेटा पढ़ना। मैंने इसे एक उदाहरण के साथ दिखाया। आपके कॉन्फ़िगरेशन को पढ़ा और पहुँचा जा सकता है, टोकन और पासवर्ड।

SSRF की तलाश कहाँ करें?

यह एक मानक भेद्यता नहीं है। यह अलग-अलग, अक्सर सबसे अप्रत्याशित स्थानों में पाया जा सकता है। इस स्थिति में, तकनीक "यहां देखें, लेकिन आप यहां भी नहीं देख सकते हैं" काम नहीं करता है।
संभावित SSRF के संकेत:

• वेबहूक । यदि वे खराब तरीके से कॉन्फ़िगर किए गए हैं, अगर फ़ायरवॉल उन सर्वरों पर अनुचित रूप से कॉन्फ़िगर किया गया है जिनसे Webhooks अनुरोध करते हैं, तो एक भेद्यता प्राप्त की जा सकती है;
• HTML रूपांतरण । <Iframe> , <img> , <base> , <script> या CSS url का निर्माण करने की कोशिश करें जो एक आंतरिक सेवा को इंगित करता है;
• हटाई गई फ़ाइलें डाउनलोड करें । अवतार उदाहरण याद है? जब किसी उपयोगकर्ता के पास URL द्वारा सर्वर पर डेटा अपलोड करने का अवसर होता है, तो यह बड़ी समस्याओं का कारण बनता है। पोर्ट के साथ URL भेजने की कोशिश करें और देखें कि क्या सामग्री अपलोड की गई है।

SSRF की खोज कैसे करें?

• सर्वर उठाएँ और श्रोता को चलाएँ:
  

  user$ nc -1 -n -vv -p 8080 -k 

  
  इस तरह आपको पोर्ट 8080 पर आपके सर्वर पर आने वाले सभी अनुरोध दिखाई देंगे। एक ओर, यह आपके वेब सर्वरों द्वारा एक अनुपयोगी पोर्ट है, और दूसरी ओर, यह एक पोर्ट है जिसे अक्सर फ़ायरवॉल द्वारा फ़िल्टर नहीं किया जाता है। यह माना जाता है कि इसका उपयोग http प्रोटोकॉल के लिए किया जाता है और इसे प्रतिबंधित करना वैकल्पिक प्रतीत होता है;
• अध्ययन के तहत आवेदन में, उस पैरामीटर को ढूंढें जिसमें आप हमारे मेजबान (हमारे श्रोता ) से डेटा का अनुरोध करने के लिए पथ को पारित कर सकते हैं;
• सूची के आउटपुट की जांच करें या प्रतिक्रिया लौटा दी जाए।

XXE (XML बाहरी इकाई)

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



डाउनलोड करने के लिए, सेवा निर्दिष्ट साइट तक पहुंचती है और क्रॉलर साइटमैप डाउनलोड करता है। xml फ़ाइल। और यह बहुत ही XML है जिसके बारे में हम इस ब्लॉक में बात कर रहे हैं।
वीडियो में, हम यह देख सकते हैं कि हमलावर साइट ने बाहरी इकाई XXE की साइटमेप. xml में एक परिभाषा कैसे जोड़ दी, जो " फ़ाइल: /// आदि / होस्ट " को इंगित करती है। लिनक्स सिस्टम पर, यह एक फाइल है जो यह बताती है कि कौन सा आईपी मेजबानों से मेल खाता है अगर उनके लिए कोई डीएनएस रिकॉर्ड नहीं है।
अगला, हमलावर <loc> में इस चर के विस्तार का संकेत देता है। XML को पार्स करने के बाद , सभी XML को डिब्बे में संसाधित करने के बाद, वह मान उस " फ़ाइल: /// आदि / होस्ट " में स्थान चर में (वीडियो में लाल रंग में हाइलाइट किया गया) सम्मिलित करेगा।
हमलावर हमारे पार्सर की शुरूआत करता है, लॉग पर जाता है, और यहां एक पंक्ति दिखाई देती है, वीडियो पर सफेद में हाइलाइट किया गया है। यह GET अनुरोध में प्राप्त फ़ाइल " फ़ाइल: /// आदि / होस्ट " की सामग्री है जो इसके द्वारा नियंत्रित सर्वर के लॉग में है।
आगे क्या है? हमलावर यह सत्यापित करेगा कि वह सही था। फ़ाइल का नाम " फ़ाइल: /// आदि / fstab " में बदलें, पार्सर को फिर से चलाएं और चल रही प्रक्रियाओं पर आंकड़े प्राप्त करें।

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

XXE का एक और उदाहरण:

मान लीजिए हमारे पास एक निश्चित समापन बिंदु है , इसे कहा जाता है - example.com/xxe ।
हम इसे XML संरचना भेजते हैं → XML में हम इकाई की घोषणा करते हैं entity → इकाई सिस्टम फ़ाइल / etc / passwd को संदर्भित करती है और प्रतिक्रिया के शरीर में आगे खुलती है → हमें प्रतिक्रिया में इस फ़ाइल की सामग्री मिलती है।
यह ध्यान देने योग्य है कि यह उतनी बार नहीं होता जितना हम चाहते हैं।

यह काम क्यों करता है?

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

• यदि दस्तावेज़ DTD का समर्थन करता है। नीचे दिया गया उदाहरण कुछ XML दिखाता है जिसमें एक ऑर्डर संरचना है, एक उत्पाद तत्व और एक गणना तत्व है (संभवतः: उत्पाद की इन्वेंट्री संख्या और ऑर्डर में आइटम की संख्या)। आदेश इन दो तत्वों के लिए मूल है:
  
• स्थानीय सर्वर पर बाहरी DTDs।
  हम पहले अवतार की तरह ही करते हैं, लेकिन हम एक अलग फ़ाइल में सभी परिभाषाएँ बनाते हैं, जो स्थानीय सर्वर पर स्थित है:
  
  
• तृतीय-पक्ष सर्वर पर बाहरी DTDs:
  

यदि आप एक चौकस पाठक हैं, तो आपने शायद इस तथ्य को सहसंबद्ध किया है कि आपकी सेवा पर इस तरह के अनुरोध करने और बाहरी DTD योजनाओं का अनुरोध करने की क्षमता अपने आप में एक भेद्यता है, जिसके बारे में हमने ऊपर बात की है, अर्थात् SSRF भेद्यता।
एक सामान्य घटना: डेवलपर्स XXE भेद्यता को ठीक करते हैं, लेकिन बाहरी DTDs के प्रसंस्करण को रोकना और SSRF प्राप्त करना भूल जाते हैं। घातक परिणाम इस से पालन नहीं करेंगे, लेकिन आपको इसके बारे में नहीं भूलना चाहिए।

XML में एंटिटीज क्या हैं?

XML में प्रविष्टियाँ । यह क्या है यह कुछ मूल्यों को परिभाषित करने और उन्हें चर में चलाने का एक अवसर है। संस्थाओं के तीन अलग-अलग प्रकार हैं:

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

XXE के लिए कहां देखें?

कई विकल्प:

• किसी भी अभिव्यक्ति में XML प्रसंस्करण:
  
  • एसवीजी;
  • साइटमैप;
• HTML को अन्य प्रारूपों में बदलें;
• डॉकएक्स , xlsx और इसी तरह के स्वरूपों को संभालना।

उनकी तलाश कैसे करें?

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

पहली चीज जो हम करते हैं: एक निश्चित इकाई जेड घोषित करते हैं, जो हमलावर मेजबान द्वारा नियंत्रित होस्ट तक पहुंचता है, इसे एक्सएमएल दस्तावेज़ के शरीर के अंदर फैलता है।
यहां दूसरा विकल्प संभव है - बस पैरामीटर का सार। पहले विज्ञापन से मुश्किल ( % संकेत)। और इस सार को चालू करने के लिए, दस्तावेज़ के शरीर की आवश्यकता नहीं है। हम इसे DOCTYPE संरचना में सीधे एक्सेस कर सकते हैं और इस इकाई को उजागर कर सकते हैं:

तीसरा परिदृश्य यह देखना है कि बाहरी सेवाओं से DOCTYPE का अनुरोध करने की क्षमता चालू या बंद है:

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

XXE से क्या खतरा है? मैं संक्षेप में और बिंदु से लिखूंगा:

• स्थानीय फ़ाइलों को पढ़ना;
• स्थानीय संसाधनों तक पहुंच;
• पोर्ट / होस्ट स्कैन
• सादा-पाठ आवरण । यह आपकी सेवाओं तक पहुंचने का एक अवसर है जो सादे-पाठ प्रोटोकॉल पर काम करता है;
• रिमोट कोड निष्पादन (अक्सर नहीं)। यह डिफ़ॉल्ट रूप से बंद है;
• DoS । इस तथ्य के कारण कि संस्थाओं को संघटित किया जा सकता है, इन मापदंडों द्वारा कब्जा की गई स्मृति की मात्रा में आसानी से एक घातीय वृद्धि प्राप्त करना संभव है। परिणाम एक बिलियन हंसी का हमला है । दूसरे शब्दों में, आप बस अटैक किए गए सर्वर की मेमोरी को ओवरलोड कर रहे हैं।

अंत में, मैं कहूंगा कि यह सब (लेख, और आपके द्वारा प्राप्त किया गया कोई भी ज्ञान) व्यावहारिक अनुप्रयोग के बिना समझ में नहीं आता है। इसलिए, मैं आपसे वास्तविक ट्रिफ़ल के बारे में पूछूंगा: उस एप्लिकेशन के बारे में सोचें जो आपने कल लिखा / परीक्षण किया था और कमजोरियों के लिए इसे जांचने का प्रयास करें। क्या कोई इनपुट फॉर्म या XML प्रोसेसिंग हैं? क्या यह एप्लिकेशन संरक्षित है? क्या फ़िल्टरिंग और DTD अक्षम है?
SQLmap मैनुअल खोलें और इसके साथ अपने आवेदन की जांच करने का तरीका जानें। अगर उसे कुछ नहीं मिलता है, तो एक और उपकरण लें और उसकी जांच करें, और फिर अन्य कमजोरियों के लिए अपने आवेदन का परीक्षण करें। जैसा कि मैंने शुरुआत में कहा था, लेख केवल कुछ कमजोरियों की जांच करता है, लेकिन उनमें से हजारों ।
मुझे विश्वास नहीं है कि आप बिल्कुल सुरक्षित कोड लिख सकते हैं। हमेशा कमजोरियाँ होती हैं, आपने अभी तक उन्हें ढूंढा नहीं है ।