* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Utilisez [**Trickest**](https://trickest.io/) pour créer et **automatiser des workflows** alimentés par les outils communautaires les plus avancés au monde.\
Si vous découvrez un domaine (domaine.tld) qui est **utilisé par un service dans le cadre** mais que l'**entreprise** a **perdu la propriété** de celui-ci, vous pouvez essayer de **l'enregistrer** (si c'est assez bon marché) et informer l'entreprise. Si ce domaine reçoit des **informations sensibles** telles qu'un cookie de session via un **paramètre GET** ou dans l'en-tête **Referer**, cela constitue une **vulnérabilité**.
Un sous-domaine de l'entreprise pointe vers un **service tiers avec un nom non enregistré**. Si vous pouvez **créer** un **compte** dans ce **service tiers** et **enregistrer** le **nom** en cours d'utilisation, vous pouvez effectuer la prise de contrôle de sous-domaine.
Si ce cookie est émis par un serveur web résidant sur _example.com_, seul ce serveur peut y accéder ultérieurement. Cependant, le cookie peut être émis pour un domaine générique (pour les raisons expliquées ci-dessus) de la manière suivante :
Le cookie sera inclus dans les requêtes HTTP vers _example.com_ mais également vers tout autre sous-domaine tel que _subdomain.example.com_. Ce comportement crée une possibilité d'attaques de gravité élevée en utilisant la prise en charge de sous-domaine. Supposons qu'un domaine particulier utilise des cookies de session pour un domaine générique. S'il y a un sous-domaine vulnérable à la prise en charge de sous-domaine, la seule chose à faire pour recueillir le jeton de session de l'utilisateur est de le tromper en visitant le sous-domaine vulnérable. Le cookie de session est automatiquement envoyé avec la requête HTTP.
* **Cookie HttpOnly** - Les cookies peuvent par défaut être accessibles par le code Javascript s'exécutant dans le contexte du site Web qui a créé les cookies. Javascript peut lire, mettre à jour et supprimer les cookies. Le drapeau de cookie _HttpOnly_ (défini par le serveur Web) indique que le cookie particulier ne peut pas être accédé par le code Javascript. La seule façon de l'obtenir est par le biais des en-têtes de requête et de réponse HTTP.
* **Cookie sécurisé** - Lorsque le cookie a le drapeau _Secure_ défini par le serveur Web, il peut être communiqué de nouveau au serveur Web uniquement si HTTPS est utilisé.
Si le domaine est vulnérable à la prise en charge de sous-domaine, un attaquant peut recueillir des cookies émis par ce domaine dans le passé en trompant les utilisateurs pour qu'ils visitent ce site Web. Les drapeaux HttpOnly et Secure ne sont pas utiles car le cookie n'est pas accédé à l'aide de Javascript et le certificat SSL peut être facilement généré pour le domaine pris.
Le vol de cookies en utilisant la prise en charge a été expliqué dans le rapport de prime de bogues [report](https://hackerone.com/reports/172137) par Arne Swinnen. Le rapport explique le problème avec l'un des sous-domaines de _Ubiquiti Networks_ (_ping.ubnt.com_). Ce sous-domaine était vulnérable à la prise en charge de sous-domaine, pointant vers une distribution AWS CloudFront non réclamée. Étant donné qu'Ubiquiti Networks utilise SSO avec des cookies de session génériques, tous les utilisateurs visitant _ping.ubnt.com_ pourraient avoir leurs cookies de session volés. Même si ce domaine pointe vers AWS CloudFront, les paramètres de distribution de CloudFront permettent de journaliser les cookies avec chaque requête. Par conséquent, le scénario d'extraction de cookies de session est entièrement possible même avec des sous-domaines pointant vers AWS CloudFront. En 2017, Arne a également démontré un vecteur d'attaque similaire contre le système SSO d'[Uber](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/).
Le comportement expliqué ci-dessus ne se limite pas aux cookies. Étant donné que les scripts Javascript ont un contrôle total sur les sites Web sur lesquels ils sont exécutés, la capacité de remplacer de tels scripts sur le site Web légitime pourrait entraîner des conséquences catastrophiques. Supposons que le site Web utilise du code Javascript provenant du fournisseur externe à l'aide de la balise _script_ et de l'attribut _src_. Lorsque le domaine du fournisseur externe expire, le navigateur échoue silencieusement, c'est-à-dire qu'il ne déclenche pas d'alertes visibles pour les utilisateurs réguliers. Si le code externe ne fait rien d'important (par exemple, il est utilisé uniquement pour le suivi), un tel fournisseur externe peut rester sur le site Web pendant une période prolongée. Un attaquant peut prendre le contrôle de ce domaine expiré, faire correspondre le chemin d'URL du code Javascript fourni et ainsi prendre le contrôle de chaque visiteur qui visite le site Web d'origine.
Il existe cependant un moyen de protéger l'intégrité des fichiers Javascript dans un navigateur. _Subresource Integrity_ [a été proposé](https://www.w3.org/TR/2016/REC-SRI-20160623/) comme mécanisme pour inclure le hachage cryptographique en tant qu'attribut _integrity_ à la balise _script_ dans HTML5. Lorsque le hachage cryptographique fourni ne correspond pas au fichier de téléchargement, le navigateur refuse de l'exécuter.
Lorsque la prise en charge de sous-domaine CNAME est possible, des enregistrements MX peuvent également être configurés par un attaquant vers un serveur Web arbitraire. Cela permet de recevoir des e-mails sur un sous-domaine légitime d'une certaine marque - particulièrement utile à nouveau dans les attaques de (spear) phishing où l'interaction entre un attaquant et une victime est nécessaire. Les attaquants falsifient généralement l'en-tête `Return-Path` pour recevoir
