Server Side Inclusion/Edge Side Inclusion Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
(Introduction taken from Apache docs)
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.
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:
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 inject arbitrary content on the document before it's sent to the users.
The following header in a response from the server means that the server is using ESI:
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:
GoSecure created a table to understand possible attacks that we can try against different ESI-capable software, depending on the functionality supported:
Includes: Supports the <esi:includes> directive
Vars: Supports the <esi:vars> directive. Useful for bypassing XSS Filters
Cookie: Document cookies are accessible to the ESI engine
Upstream Headers Required: Surrogate applications will not process ESI statements unless the upstream application provides the headers
Host Allowlist: In this case, ESI includes are only possible from allowed server hosts, making SSRF, for example, only possible against those hosts
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
The following ESI directive will load an arbitrary file inside the response of the server
Remote steal cookie
Steal cookie HTTP_ONLY with XSS by reflecting it in the response:
Do not confuse this with a "Local File Inclusion":
The following will add a Location header to the response
Add header in forced request
Add header in response (useful to bypass "Content-Type: text/json" in a response with XSS)
This will send debug information included in the response:
It's possible to use eXtensible Stylesheet Language Transformations (XSLT) syntax in ESI just by indicating the param dca value as xslt. Which might allow to abuse XSLT to create and abuse a XML External Entity vulnerability (XXE):
XSLT file:
Check the XSLT page:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
