mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 05:03:35 +00:00
Translated ['pentesting-web/race-condition.md'] to fr
This commit is contained in:
Translator
parent
66b1d123d9
commit
ec6f753f92
1 changed files with 41 additions and 41 deletions
|
|
@ -3,42 +3,42 @@
|
|||
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser des flux de travail** alimentés par les outils communautaires **les plus avancés** au monde.\
|
||||
Utilisez [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) pour construire et **automatiser des workflows** grâce aux outils communautaires **les plus avancés**.\
|
||||
Obtenez l'accès aujourd'hui :
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Autres moyens de soutenir HackTricks :
|
||||
|
||||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||||
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Partagez vos astuces de piratage en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
## Exploiter les conditions de course
|
||||
|
||||
Le principal problème de l'exploitation des conditions de course est que vous avez besoin que les requêtes soient traitées en parallèle avec un très court intervalle de temps (généralement >1ms). Dans la section suivante, différentes solutions sont proposées pour rendre cela possible.
|
||||
Le principal problème pour abuser des conditions de course est que vous avez besoin que les requêtes soient traitées en parallèle avec un très court intervalle de temps (généralement >1ms). Dans la section suivante, différentes solutions sont proposées pour rendre cela possible.
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (5) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Attaque par paquet unique (HTTP/2) / Synchronisation du dernier octet (HTTP/1.1)
|
||||
|
||||
HTTP2 permet d'envoyer **2 requêtes dans une seule connexion TCP** (alors qu'en HTTP/1.1 elles doivent être séquentielles).\
|
||||
L'utilisation d'un seul paquet TCP élimine complètement **l'effet du jitter réseau**, ce qui a clairement un potentiel pour les attaques par condition de course aussi. Cependant, **deux requêtes ne suffisent pas pour une attaque de course fiable** à cause du **jitter côté serveur** - variations dans le temps de traitement des requêtes de l'application causées par des variables incontrôlables comme la contention CPU.
|
||||
L'utilisation d'un seul paquet TCP **élimine complètement l'effet du jitter réseau**, ce qui a clairement un potentiel pour les attaques par condition de course aussi. Cependant, **deux requêtes ne suffisent pas pour une attaque de course fiable** à cause du **jitter côté serveur** - variations dans le temps de traitement des requêtes de l'application causées par des variables incontrôlables comme la contention CPU.
|
||||
|
||||
Mais, en utilisant la technique de '**synchronisation du dernier octet**' avec HTTP/1.1, il est possible de pré-envoyer la majeure partie des données en retenant un petit fragment de chaque requête, puis de 'compléter' **20-30 requêtes avec un seul paquet TCP**.
|
||||
|
||||
Pour **pré-envoyer la majeure partie de chaque requête** :
|
||||
|
||||
* Si la requête n'a pas de corps, envoyez tous les en-têtes, mais ne définissez pas le drapeau END\_STREAM. Retenez un cadre de données vide avec END\_STREAM défini.
|
||||
* Si la requête a un corps, envoyez les en-têtes et toutes les données du corps sauf le dernier octet. Retenez un cadre de données contenant le dernier octet.
|
||||
* Si la requête a un corps, envoyez les en-têtes et toutes les données du corps sauf le dernier octet et le drapeau END\_STREAM. Retenez un cadre de données contenant le dernier octet.
|
||||
|
||||
Ensuite, **préparez-vous à envoyer les cadres finaux** :
|
||||
|
||||
|
|
@ -58,15 +58,15 @@ En utilisant cette technique, vous pouvez faire en sorte que 20-30 requêtes arr
|
|||
|
||||
**Adaptation à l'architecture cible**
|
||||
|
||||
Il convient de noter que de nombreuses applications sont situées derrière un serveur frontal, et celles-ci peuvent décider de transférer certaines requêtes via des connexions existantes vers le back-end, et de créer de nouvelles connexions pour d'autres.
|
||||
Il est important de noter que de nombreuses applications sont situées derrière un serveur frontal, et celles-ci peuvent décider de transférer certaines requêtes via des connexions existantes vers le back-end, et de créer de nouvelles connexions pour d'autres.
|
||||
|
||||
En conséquence, il est important de ne pas attribuer un temps de traitement des requêtes incohérent au comportement de l'application, tel que des mécanismes de verrouillage qui ne permettent qu'à un seul thread d'accéder à une ressource à la fois. De plus, le routage des requêtes frontales est souvent effectué sur une base par connexion, donc vous pourriez être en mesure de lisser le temps de traitement des requêtes en effectuant un réchauffement de connexion côté serveur - **envoyer quelques requêtes insignifiantes dans votre connexion avant de réaliser l'attaque** (cela consiste juste à envoyer plusieurs requêtes avant de commencer l'attaque réelle).
|
||||
En conséquence, il est important de ne pas attribuer un timing de requête incohérent au comportement de l'application, tel que des mécanismes de verrouillage qui ne permettent qu'à un seul thread d'accéder à une ressource à la fois. De plus, le routage des requêtes frontales est souvent effectué sur une base par connexion, donc vous pourriez être en mesure d'améliorer le timing des requêtes en effectuant un réchauffement de connexion côté serveur - **envoyer quelques requêtes insignifiantes dans votre connexion avant de réaliser l'attaque** (cela consiste juste à envoyer plusieurs requêtes avant de commencer l'attaque réelle).
|
||||
|
||||
#### Mécanismes de verrouillage basés sur la session <a href="#session-based-locking-mechanisms" id="session-based-locking-mechanisms"></a>
|
||||
|
||||
Certains frameworks tentent de prévenir la corruption accidentelle des données en utilisant une forme de **verrouillage des requêtes**. Par exemple, le module de gestion de session natif de **PHP** ne traite qu'**une requête par session à la fois**.
|
||||
Certains frameworks tentent de prévenir la corruption accidentelle des données en utilisant une forme de **verrouillage des requêtes**. Par exemple, le module de gestion de session natif de **PHP** ne traite **qu'une requête par session à la fois**.
|
||||
|
||||
Il est extrêmement important de repérer ce type de comportement car il peut sinon masquer des vulnérabilités trivialement exploitables. Si vous remarquez que toutes vos requêtes sont traitées séquentiellement, essayez d'envoyer chacune d'elles en utilisant un jeton de session différent.
|
||||
Il est extrêmement important de repérer ce type de comportement car il peut sinon masquer des vulnérabilités trivialement exploitables. Si vous remarquez que toutes vos requêtes sont traitées séquentiellement, essayez d'envoyer chacune d'elles en utilisant un token de session différent.
|
||||
|
||||
#### **Abuser des limites de taux ou de ressources**
|
||||
|
||||
|
|
@ -86,9 +86,9 @@ Les serveurs Web retardent souvent le traitement des requêtes si trop sont envo
|
|||
Pour plus d'informations sur cette technique, consultez le rapport original sur [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
|
||||
{% endhint %}
|
||||
|
||||
#### Exemples d'attaque
|
||||
#### Exemples d'attaques
|
||||
|
||||
* **Tubo Intruder - Attaque par paquet unique HTTP2 (1 point de terminaison)** : Vous pouvez envoyer la requête à **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Envoyer à Turbo Intruder`), vous pouvez changer dans la requête la valeur que vous souhaitez forcer par brute force pour **`%s`** comme dans `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` puis sélectionnez **`examples/race-single-packer-attack.py`** dans le menu déroulant :
|
||||
* **Turbo Intruder - Attaque par paquet unique HTTP2 (1 point de terminaison)** : Vous pouvez envoyer la requête à **Turbo Intruder** (`Extensions` -> `Turbo Intruder` -> `Envoyer à Turbo Intruder`), vous pouvez changer dans la requête la valeur que vous souhaitez forcer pour **`%s`** comme dans `csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s` puis sélectionnez le **`examples/race-single-packer-attack.py`** dans le menu déroulant :
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (4) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ for password in passwords:
|
|||
engine.queue(target.req, password, gate='race1')
|
||||
```
|
||||
{% hint style="warning" %}
|
||||
Si le web ne prend pas en charge HTTP2 (seulement HTTP1.1), utilisez `Engine.THREADED` ou `Engine.BURP` au lieu de `Engine.BURP2`.
|
||||
Si le web ne supporte pas HTTP2 (seulement HTTP1.1), utilisez `Engine.THREADED` ou `Engine.BURP` au lieu de `Engine.BURP2`.
|
||||
{% endhint %}
|
||||
|
||||
* **Tubo Intruder - Attaque en un seul paquet HTTP2 (Plusieurs points de terminaison)** : Si vous devez envoyer une requête à 1 point de terminaison puis plusieurs à d'autres points de terminaison pour déclencher le RCE, vous pouvez modifier le script `race-single-packet-attack.py` avec quelque chose comme :
|
||||
|
|
@ -136,7 +136,7 @@ engine.openGate(currentAttempt)
|
|||
* Il est également disponible dans **Repeater** via la nouvelle option '**Envoyer le groupe en parallèle**' dans Burp Suite.
|
||||
* Pour un **dépassement de limite**, vous pourriez simplement ajouter **la même requête 50 fois** dans le groupe.
|
||||
* Pour le **préchauffage de connexion**, vous pourriez **ajouter** au **début** du **groupe** quelques **requêtes** vers une partie non statique du serveur web.
|
||||
* Pour **retarder** le processus **entre** le traitement **d'une requête et d'une autre** en 2 étapes de sous-états, vous pourriez **ajouter des requêtes supplémentaires entre** les deux requêtes.
|
||||
* Pour **retarder** le processus **entre** le traitement **d'une requête et une autre** en 2 étapes de sous-états, vous pourriez **ajouter des requêtes supplémentaires entre** les deux requêtes.
|
||||
* Pour un RC **multi-point d'accès**, vous pourriez commencer par envoyer la **requête** qui **va vers l'état caché** puis **50 requêtes** juste après qui **exploitent l'état caché**.
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
|
@ -145,8 +145,8 @@ engine.openGate(currentAttempt)
|
|||
|
||||
Avant les recherches précédentes, voici quelques charges utiles utilisées qui tentaient simplement d'envoyer les paquets aussi rapidement que possible pour provoquer un RC.
|
||||
|
||||
* **Repeater :** Vérifiez les exemples de la section précédente.
|
||||
* **Intruder :** Envoyez la **requête** à **Intruder**, réglez le **nombre de threads** à **30** dans le **menu Options**, sélectionnez comme charge utile **Null payloads** et générez **30**.
|
||||
* **Repeater :** Consultez les exemples de la section précédente.
|
||||
* **Intruder :** Envoyez la **requête** à **Intruder**, réglez le **nombre de threads** sur **30** dans le **menu Options**, sélectionnez comme charge utile **Null payloads** et générez **30**.
|
||||
* **Turbo Intruder**
|
||||
```python
|
||||
def queueRequests(target, wordlists):
|
||||
|
|
@ -214,19 +214,19 @@ D'autres RC plus compliqués exploiteront les **sous-états dans l'état de la m
|
|||
|
||||
1. **Prédire les sous-états cachés et intéressants potentiels**
|
||||
|
||||
La première étape consiste à identifier tous les points de terminaison qui écrivent dessus, ou lisent des données à partir de celui-ci, puis utilisent ces données pour quelque chose d'important. Par exemple, les utilisateurs peuvent être stockés dans une table de base de données qui est modifiée par l'inscription, les modifications de profil, l'initiation de réinitialisation de mot de passe et la finalisation de réinitialisation de mot de passe.
|
||||
La première étape consiste à identifier tous les points de terminaison qui écrivent dessus, ou lisent des données à partir de celui-ci et utilisent ensuite ces données pour quelque chose d'important. Par exemple, les utilisateurs peuvent être stockés dans une table de base de données qui est modifiée par l'inscription, les modifications de profil, l'initiation de réinitialisation de mot de passe et la complétion de réinitialisation de mot de passe.
|
||||
|
||||
Nous pouvons utiliser trois questions clés pour écarter les points de terminaison qui sont peu susceptibles de provoquer des collisions. Pour chaque objet et les points de terminaison associés, demandez :
|
||||
|
||||
* **Comment l'état est-il stocké ?**
|
||||
|
||||
Les données stockées dans une structure de données persistante côté serveur sont idéales pour l'exploitation. Certains points de terminaison stockent leur état entièrement côté client, comme les réinitialisations de mot de passe qui fonctionnent en envoyant un JWT par e-mail - ceux-ci peuvent être ignorés en toute sécurité.
|
||||
Les données stockées dans une structure de données persistante côté serveur sont idéales pour l'exploitation. Certains points de terminaison stockent leur état entièrement côté client, comme les réinitialisations de mot de passe qui fonctionnent en envoyant un JWT par email - ceux-ci peuvent être ignorés en toute sécurité.
|
||||
|
||||
Les applications stockent souvent un certain état dans la session utilisateur. Celles-ci sont souvent quelque peu protégées contre les sous-états - plus de détails à venir.
|
||||
Les applications stockent souvent un certain état dans la session utilisateur. Celles-ci sont souvent quelque peu protégées contre les sous-états - plus à ce sujet plus tard.
|
||||
|
||||
* **Modifions-nous ou ajoutons-nous ?**
|
||||
|
||||
Les opérations qui modifient des données existantes (telles que le changement de l'adresse e-mail principale d'un compte) ont un potentiel de collision important, tandis que les actions qui ajoutent simplement à des données existantes (telles que l'ajout d'une adresse e-mail supplémentaire) sont peu susceptibles d'être vulnérables à autre chose que des attaques de dépassement de limite.
|
||||
Les opérations qui modifient des données existantes (telles que changer l'adresse email principale d'un compte) ont un potentiel de collision important, tandis que les actions qui ajoutent simplement à des données existantes (telles que l'ajout d'une adresse email supplémentaire) sont peu susceptibles d'être vulnérables à autre chose que des attaques de dépassement de limite.
|
||||
|
||||
* **Sur quoi l'opération est-elle basée ?**
|
||||
|
||||
|
|
@ -236,19 +236,19 @@ La plupart des points de terminaison opèrent sur un enregistrement spécifique,
|
|||
|
||||
2. **Chercher des indices**
|
||||
|
||||
À ce stade, il est temps de **lancer des attaques RC** sur les points de terminaison potentiellement intéressants pour essayer de trouver des résultats inattendus par rapport aux résultats habituels. **Tout écart par rapport à la réponse attendue**, comme un changement dans une ou plusieurs réponses, ou un effet secondaire comme un contenu d'e-mail différent ou un changement visible dans votre session, pourrait être un indice indiquant que quelque chose ne va pas.
|
||||
À ce stade, il est temps de **lancer des attaques RC** sur les points de terminaison potentiellement intéressants pour essayer de trouver des résultats inattendus par rapport aux réponses habituelles. **Tout écart par rapport à la réponse attendue**, comme un changement dans une ou plusieurs réponses, ou un effet secondaire comme un contenu d'email différent ou un changement visible dans votre session pourrait être un indice indiquant que quelque chose ne va pas.
|
||||
|
||||
3. **Prouver le concept**
|
||||
|
||||
La dernière étape consiste à **prouver le concept et à le transformer en une attaque viable**.
|
||||
|
||||
Lorsque vous envoyez un lot de requêtes, vous pouvez constater qu'une paire de requêtes initiales déclenche un état final vulnérable, mais que les requêtes ultérieures l'écrasent/l'invalident et que l'état final n'est pas exploitable. Dans ce scénario, vous voudrez éliminer toutes les requêtes inutiles - deux devraient suffire pour exploiter la plupart des vulnérabilités. Cependant, réduire à deux requêtes rendra l'attaque plus sensible au timing, vous devrez donc peut-être réessayer l'attaque plusieurs fois ou l'automatiser.
|
||||
Lorsque vous envoyez un lot de requêtes, vous pouvez constater qu'une paire de requêtes initiales déclenche un état final vulnérable, mais que les requêtes ultérieures l'écrasent/le rendent invalide et que l'état final n'est pas exploitable. Dans ce scénario, vous voudrez éliminer toutes les requêtes inutiles - deux devraient suffire pour exploiter la plupart des vulnérabilités. Cependant, réduire à deux requêtes rendra l'attaque plus sensible au timing, vous devrez donc peut-être réessayer l'attaque plusieurs fois ou l'automatiser.
|
||||
|
||||
### Attaques sensibles au temps
|
||||
|
||||
Parfois, vous ne trouverez peut-être pas de conditions de concurrence, mais les **techniques pour envoyer des requêtes avec un timing précis** peuvent encore révéler la présence d'autres vulnérabilités.
|
||||
Parfois, vous ne trouverez pas de conditions de concurrence, mais les **techniques pour envoyer des requêtes avec un timing précis** peuvent encore révéler la présence d'autres vulnérabilités.
|
||||
|
||||
Un tel exemple est lorsque des **horodatages de haute résolution sont utilisés au lieu de chaînes aléatoires cryptographiquement** sécurisées pour générer des jetons de sécurité.
|
||||
Un tel exemple est lorsque des **horodatages de haute résolution sont utilisés au lieu de chaînes aléatoires sécurisées cryptographiquement** pour générer des jetons de sécurité.
|
||||
|
||||
Considérez un **jeton de réinitialisation de mot de passe qui est seulement randomisé en utilisant un horodatage**. Dans ce cas, il pourrait être possible de **déclencher deux réinitialisations de mot de passe pour deux utilisateurs différents**, qui utilisent tous les deux le **même jeton**. Tout ce que vous avez à faire est de synchroniser les requêtes pour qu'elles génèrent le même horodatage.
|
||||
|
||||
|
|
@ -256,21 +256,21 @@ Considérez un **jeton de réinitialisation de mot de passe qui est seulement ra
|
|||
Pour confirmer par exemple la situation précédente, vous pourriez simplement demander **2 jetons de réinitialisation de mot de passe en même temps** (en utilisant une attaque par paquet unique) et vérifier s'ils sont les **mêmes**.
|
||||
{% endhint %}
|
||||
|
||||
Vérifiez [**l'exemple dans ce laboratoire**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities).
|
||||
Vérifiez l'[**exemple dans ce laboratoire**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities).
|
||||
|
||||
## Études de cas de sous-états cachés
|
||||
## Études de cas sur les sous-états cachés
|
||||
|
||||
### Payer & ajouter un article
|
||||
|
||||
[**Vérifiez ce laboratoire**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation) pour voir comment **payer** dans un magasin et **ajouter un article supplémentaire** que vous **n'aurez pas à payer**.
|
||||
|
||||
### Confirmer d'autres e-mails
|
||||
### Confirmer d'autres emails
|
||||
|
||||
L'idée est de **vérifier une adresse e-mail et de la changer pour une autre en même temps** pour découvrir si la plateforme vérifie la nouvelle qui a été changée.
|
||||
L'idée est de **vérifier une adresse email et de la changer pour une autre en même temps** pour découvrir si la plateforme vérifie la nouvelle changée.
|
||||
|
||||
### Changer d'e-mail en 2 adresses e-mail basées sur les cookies
|
||||
### Changer d'email pour 2 adresses emails basées sur Cookie
|
||||
|
||||
Selon [**ce compte-rendu**](https://portswigger.net/research/smashing-the-state-machine), Gitlab était vulnérable à une prise de contrôle de cette manière car il pourrait **envoyer** le **jeton de vérification d'e-mail d'un e-mail à l'autre e-mail**.
|
||||
Selon [**ce compte-rendu**](https://portswigger.net/research/smashing-the-state-machine) Gitlab était vulnérable à une prise de contrôle de cette manière car il pourrait **envoyer** le **jeton de vérification d'email d'un email à l'autre email**.
|
||||
|
||||
Vous pouvez également vérifier [**ce laboratoire**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint) pour en savoir plus à ce sujet.
|
||||
|
||||
|
|
@ -278,13 +278,13 @@ Vous pouvez également vérifier [**ce laboratoire**](https://portswigger.net/we
|
|||
|
||||
Si **2 écritures différentes** sont utilisées pour **ajouter** des **informations** dans une **base de données**, il existe une petite portion de temps où **seules les premières données ont été écrites** dans la base de données. Par exemple, lors de la création d'un utilisateur, le **nom d'utilisateur** et le **mot de passe** pourraient être **écrits** et **ensuite le jeton** pour confirmer le compte nouvellement créé est écrit. Cela signifie que pendant un court moment, le **jeton pour confirmer un compte est nul**.
|
||||
|
||||
Par conséquent, **enregistrer un compte et envoyer plusieurs requêtes avec un jeton vide** (`token=` ou `token[]=` ou toute autre variation) pour confirmer le compte immédiatement pourrait permettre de **confirmer un compte** où vous ne contrôlez pas l'e-mail.
|
||||
Par conséquent, **enregistrer un compte et envoyer plusieurs requêtes avec un jeton vide** (`token=` ou `token[]=` ou toute autre variation) pour confirmer le compte immédiatement pourrait permettre de **confirmer un compte** où vous ne contrôlez pas l'email.
|
||||
|
||||
Vérifiez [**ce laboratoire**](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction) pour voir un exemple.
|
||||
|
||||
### Contourner le 2FA
|
||||
|
||||
Le pseudo-code suivant montre comment un site Web pourrait être vulnérable à une variation de course de cette attaque :
|
||||
Le pseudo-code suivant montre comment un site web pourrait être vulnérable à une variation de course de cette attaque :
|
||||
```python
|
||||
session['userid'] = user.userid
|
||||
if user.mfa_enabled:
|
||||
|
|
@ -292,16 +292,16 @@ session['enforce_mfa'] = True
|
|||
# generate and send MFA code to user
|
||||
# redirect browser to MFA code entry form
|
||||
```
|
||||
Comme vous pouvez le voir, il s'agit en fait d'une **séquence multi-étapes dans la durée d'une seule requête**. Plus important encore, elle passe par un sous-état dans lequel l'**utilisateur a temporairement une session valide connectée**, **mais l'authentification multifacteur n'est pas encore appliquée**. Un attaquant pourrait potentiellement exploiter cela en envoyant une demande de connexion avec une demande à un point de terminaison sensible et authentifié.
|
||||
Comme vous pouvez le voir, il s'agit en fait d'une **séquence multi-étapes dans la durée d'une seule requête**. Plus important encore, elle passe par un sous-état dans lequel **l'utilisateur a temporairement une session valide connectée**, **mais l'authentification multifacteur n'est pas encore appliquée**. Un attaquant pourrait potentiellement exploiter cela en envoyant une demande de connexion avec une demande à un point de terminaison sensible et authentifié.
|
||||
|
||||
### Persistance éternelle OAuth2
|
||||
|
||||
Il existe plusieurs [**fournisseurs OAuth**](https://en.wikipedia.org/wiki/List_of_OAuth_providers). Ces services vous permettent de créer une application et d'authentifier les utilisateurs que le fournisseur a enregistrés. Pour ce faire, le **client** devra **autoriser votre application** à accéder à certaines de leurs données à l'intérieur du **fournisseur OAuth**.\
|
||||
Jusqu'ici, juste une connexion classique avec google/linkdin/github... où une page s'affiche disant : "_L'application \<InsertCoolName> souhaite accéder à vos informations, voulez-vous l'autoriser ?_"
|
||||
Jusqu'ici, juste une connexion classique avec Google/LinkedIn/GitHub... où une page s'affiche disant : "_L'application \<InsertCoolName> souhaite accéder à vos informations, voulez-vous l'autoriser ?_"
|
||||
|
||||
#### Condition de concurrence dans `authorization_code`
|
||||
|
||||
Le **problème** apparaît lorsque vous **l'acceptez** et qu'un **`authorization_code`** est automatiquement envoyé à l'application malveillante. Ensuite, cette **application abuse d'une condition de concurrence dans le fournisseur de services OAuth pour générer plus d'un AT/RT** (_Token d'Authentification/Token de Rafraîchissement_) à partir du **`authorization_code`** pour votre compte. En gros, elle abuse du fait que vous avez accepté l'application pour accéder à vos données pour **créer plusieurs comptes**. Ensuite, si vous **arrêtez d'autoriser l'application à accéder à vos données, une paire d'AT/RT sera supprimée, mais les autres resteront valides**.
|
||||
Le **problème** apparaît lorsque vous **l'acceptez** et que cela envoie automatiquement un **`authorization_code`** à l'application malveillante. Ensuite, cette **application abuse d'une condition de concurrence dans le fournisseur de services OAuth pour générer plus d'un AT/RT** (_Token d'Authentification/Token de Rafraîchissement_) à partir du **`authorization_code`** pour votre compte. En gros, elle va abuser du fait que vous avez accepté que l'application accède à vos données pour **créer plusieurs comptes**. Ensuite, si vous **arrêtez d'autoriser l'application à accéder à vos données, une paire d'AT/RT sera supprimée, mais les autres resteront valides**.
|
||||
|
||||
#### Condition de concurrence dans `Refresh Token`
|
||||
|
||||
|
|
@ -309,7 +309,7 @@ Une fois que vous avez **obtenu un RT valide**, vous pourriez essayer de **l'abu
|
|||
|
||||
## **RC dans WebSockets**
|
||||
|
||||
Dans [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC), vous pouvez trouver un PoC en Java pour envoyer des messages websocket en **parallèle** pour abuser des **conditions de concurrence également dans les Web Sockets**.
|
||||
Dans [**WS_RaceCondition_PoC**](https://github.com/redrays-io/WS_RaceCondition_PoC), vous pouvez trouver un PoC en Java pour envoyer des messages WebSocket en **parallèle** pour abuser des **conditions de concurrence également dans les WebSockets**.
|
||||
|
||||
## Références
|
||||
|
||||
|
|
@ -328,15 +328,15 @@ Autres moyens de soutenir HackTricks :
|
|||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
|
||||
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
Utilisez [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) pour construire et **automatiser des workflows** grâce aux outils communautaires **les plus avancés**.\
|
||||
Utilisez [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) pour construire et **automatiser des workflows** facilement, alimentés par les outils communautaires **les plus avancés**.\
|
||||
Obtenez l'accès aujourd'hui :
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
|
|
|||
Loading…
Reference in a new issue