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).
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:
Check
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:
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 exploitation
XSS
The following ESI directive will load an arbitrary file inside the response of the server
The file http://attacker.com/xss.html may contain a XSS payload like <script>alert(1)</script>
Bypass client XSS protection
Steal Cookie
Private Local File
Do not confuse this with a "Local File Inclusion":
CRLF
Akamai debug
This will send debug information included in the response:
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.
The XSLT file:
Check the XSLT page:
XSLT Server Side Injection (Extensible Stylesheet Languaje Transformations)References
Brute-Force Detection List
Last updated