Server Side Inclusion/Edge Side Inclusion Injection
Server Side Inclusion Basic Information
SSI (Server Side Includes) ऐसे निर्देश हैं जो HTML पृष्ठों में रखे जाते हैं, और सर्वर पर मूल्यांकित होते हैं जब पृष्ठों को परोसा जा रहा होता है। ये आपको एक मौजूदा HTML पृष्ठ में गतिशील रूप से उत्पन्न सामग्री जोड़ने की अनुमति देते हैं, बिना पूरे पृष्ठ को CGI प्रोग्राम या अन्य गतिशील तकनीक के माध्यम से परोसने की आवश्यकता के। उदाहरण के लिए, आप एक मौजूदा HTML पृष्ठ में एक निर्देश रख सकते हैं, जैसे:
<!--#echo var="DATE_LOCAL" -->
और, जब पृष्ठ परोसा जाता है, तो यह अंश मूल्यांकित किया जाएगा और इसके मान से प्रतिस्थापित किया जाएगा:
Tuesday, 15-Jan-2013 19:28:54 EST
SSI का उपयोग कब करना है, और कब आपके पृष्ठ को पूरी तरह से किसी प्रोग्राम द्वारा उत्पन्न करना है, यह आमतौर पर इस बात का मामला होता है कि पृष्ठ का कितना हिस्सा स्थिर है, और कितना हर बार पृष्ठ परोसने पर पुनः गणना करने की आवश्यकता है। SSI छोटी जानकारी के टुकड़े जोड़ने का एक शानदार तरीका है, जैसे कि वर्तमान समय - जो ऊपर दिखाया गया है। लेकिन यदि आपके पृष्ठ का अधिकांश भाग उस समय उत्पन्न हो रहा है जब इसे परोसा जाता है, तो आपको किसी अन्य समाधान की तलाश करनी होगी।
आप SSI की उपस्थिति का अनुमान लगा सकते हैं यदि वेब एप्लिकेशन फ़ाइलों का उपयोग करता है जिनके एक्सटेंशन .shtml, .shtm या .stm हैं, लेकिन यह केवल यही मामला नहीं है।
एक सामान्य SSI अभिव्यक्ति का निम्नलिखित प्रारूप होता है:
जांचें
Edge Side Inclusion
एक समस्या जानकारी या गतिशील अनुप्रयोगों को कैश करना है क्योंकि सामग्री का एक भाग अगले बार सामग्री को पुनः प्राप्त करते समय भिन्न हो सकता है। यही कारण है कि ESI का उपयोग किया जाता है, ESI टैग का उपयोग करके यह संकेत देने के लिए कि गतिशील सामग्री जो उत्पन्न की जानी चाहिए उसे कैश संस्करण भेजने से पहले उत्पन्न किया जाना चाहिए। यदि एक हमलावर कैश सामग्री के अंदर एक ESI टैग इंजेक्ट करने में सक्षम है, तो वह दस्तावेज़ पर मनमाना सामग्री इंजेक्ट करने में सक्षम हो सकता है इससे पहले कि इसे उपयोगकर्ताओं को भेजा जाए।
ESI Detection
सर्वर से प्रतिक्रिया में निम्नलिखित हेडर का अर्थ है कि सर्वर ESI का उपयोग कर रहा है:
यदि आप इस हेडर को नहीं ढूंढ पा रहे हैं, तो सर्वर शायद ESI का उपयोग कर रहा है। एक अंधे शोषण दृष्टिकोण का भी उपयोग किया जा सकता है क्योंकि एक अनुरोध हमलावर के सर्वर पर पहुंचना चाहिए:
ESI शोषण
Includes:
<esi:includes>निर्देश का समर्थन करता हैVars:
<esi:vars>निर्देश का समर्थन करता है। XSS फ़िल्टर को बायपास करने के लिए उपयोगीCookie: दस्तावेज़ कुकीज़ ESI इंजन के लिए सुलभ हैं
Upstream Headers Required: सरोगेट एप्लिकेशन ESI कथनों को संसाधित नहीं करेंगे जब तक कि अपस्ट्रीम एप्लिकेशन हेडर प्रदान न करे
Host Allowlist: इस मामले में, ESI शामिल केवल अनुमत सर्वर होस्ट से संभव हैं, जिससे SSRF, उदाहरण के लिए, केवल उन होस्ट के खिलाफ संभव है
XSS
निम्नलिखित ESI निर्देश सर्वर के प्रतिक्रिया के अंदर एक मनमाना फ़ाइल लोड करेगा
क्लाइंट XSS सुरक्षा को बायपास करें
कुकी चुराना
दूरस्थ कुकी चुराना
HTTP_ONLY कुकी को XSS के माध्यम से चुराना और इसे प्रतिक्रिया में परावर्तित करना:
Private Local File
इसको "Local File Inclusion" के साथ भ्रमित न करें:
CRLF
Open Redirect
निम्नलिखित प्रतिक्रिया में Location हेडर जोड़ेगा
Add Header
मजबूर अनुरोध में हेडर जोड़ें
प्रतिक्रिया में हेडर जोड़ें (XSS के साथ "Content-Type: text/json" को बायपास करने के लिए उपयोगी)
CRLF in Add header (CVE-2019-2438)
Akamai debug
यह प्रतिक्रिया में शामिल डिबग जानकारी भेजेगा:
ESI + XSLT = XXE
xslt पैरामीटर के लिए dca मान निर्दिष्ट करके, eXtensible Stylesheet Language Transformations (XSLT) आधारित ESI को शामिल करना संभव है। समावेश HTTP सरोगेट को XML और XSLT फ़ाइलों को पुनः प्राप्त करने के लिए मजबूर करता है, जिसमें बाद वाला पूर्व को फ़िल्टर करता है। ऐसी XML फ़ाइलें XML External Entity (XXE) हमलों के लिए शोषणीय होती हैं, जिससे हमलावरों को SSRF हमले करने की अनुमति मिलती है। हालाँकि, इस दृष्टिकोण की उपयोगिता सीमित है क्योंकि ESI पहले से ही SSRF वेक्टर के रूप में कार्य करता है। अंतर्निहित Xalan पुस्तकालय में समर्थन की अनुपस्थिति के कारण, बाहरी DTDs को संसाधित नहीं किया जाता है, जिससे स्थानीय फ़ाइल निकासी को रोका जाता है।
XSLT फ़ाइल:
Check the XSLT page:
संदर्भ
ब्रूट-फोर्स डिटेक्शन लिस्ट
Last updated