# Injeção de Inclusão do Lado do Servidor/Inclusão do Lado do Edge
Aprenda hacking AWS do zero ao herói comhtARTE (HackTricks AWS Red Team Expert)!
Outras maneiras de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
## Informações Básicas sobre Inclusão do Lado do Servidor
**(Introdução retirada da [documentação do Apache](https://httpd.apache.org/docs/current/howto/ssi.html))**
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 por meio de um programa CGI ou outra tecnologia dinâmica.\
Por exemplo, você pode colocar uma diretiva em uma página HTML existente, como:
``
E, quando a página é servida, este fragmento será avaliado e substituído por seu valor:
`Terça-feira, 15-Jan-2013 19:28:54 EST`
A decisão de quando usar SSI e quando ter sua página inteiramente gerada por algum programa geralmente é uma questão de quanta parte da página é estática e quanto precisa ser recalculado toda vez que a página é servida. SSI é uma ótima maneira de adicionar pequenos pedaços de informação, como o horário atual - mostrado acima. Mas se a maioria da sua página está sendo gerada no momento em que é servida, você precisa procurar por outra solução.
Você pode inferir a presença de SSI se a aplicação web usar arquivos com as extensões \*\* `.shtml`, `.shtm` ou `.stm`\*\*, mas não é o único caso.
Uma expressão SSI típica tem o seguinte formato:
```
```
### Verificação
```javascript
// Document name
// Date
// File inclusion
// Including files (same directory)
// CGI Program results
// Including virtual files (same directory)
// Modification date of a file
// Command exec
// Command exec
// Reverse shell
// Print all variables
// Setting variables
```
## Inclusão Lateral
Existe um problema **em armazenar em cache informações ou aplicativos dinâmicos**, pois parte do conteúdo pode ter **variações** 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** for capaz de **injetar uma tag ESI** dentro do conteúdo em cache, então ele poderá **injetar conteúdo arbitrário** no documento antes que seja enviado aos usuários.
### Detecção de ESI
O seguinte **cabeçalho** em uma resposta do servidor significa que o servidor está usando ESI:
```
Surrogate-Control: content="ESI/1.0"
```
Se não conseguir encontrar este cabeçalho, o servidor **pode estar a usar ESI de qualquer forma**.\
Uma **abordagem de exploração cega também pode ser usada** pois um pedido deve chegar ao servidor do atacante:
```javascript
// Basic detection
hello
// If previous is reflected as "hello", it's vulnerable
// Blind detection
// XSS Exploitation Example
// Cookie Stealer (bypass httpOnly flag)
// Introduce private local files (Not LFI per se)
// Valid for Akamai, sends debug information in the response
```
### Exploração de ESI
[GoSecure criou](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) uma tabela para entender possíveis ataques que podemos tentar contra diferentes softwares capazes de ESI, dependendo da funcionalidade suportada:
* **Includes**: Suporta a diretiva ``
* **Vars**: Suporta a diretiva ``. Útil para contornar Filtros XSS
* **Cookie**: Os cookies do documento são acessíveis ao mecanismo ESI
* **Upstream Headers Required**: As aplicações substitutas não processarão declarações ESI a menos que a aplicação upstream forneça os cabeçalhos
* **Host Allowlist**: Neste caso, as inclusões ESI são possíveis apenas a partir de hosts de servidor permitidos, tornando SSRF, por exemplo, apenas possível contra esses hosts
| **Software** | **Includes** | **Vars** | **Cookies** | **Upstream Headers Required** | **Host Whitelist** |
| :--------------------------: | :----------: | :------: | :---------: | :---------------------------: | :----------------: |
| 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
```xml
```
#### Bypass proteção XSS do cliente
```xml
x=>alert(/Chrome%20XSS%20filter%20bypass/);>
Use to bypass WAFs:
ipt>alert(1)ript>
error=alert(1)>
```
#### Roubo de Cookie
* Roubo remoto de cookie
```xml
```
* Roubar cookie HTTP\_ONLY com XSS refletindo-o na resposta:
```bash
# This will reflect the cookies in the response
# Reflect XSS (you can put '">