> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Décrit différents types de cyberattaques et les mesures qui peuvent être prises pour les prévenir.

# Prévenir les menaces courantes en cybersécurité

Voici quelques menaces courantes en cybersécurité :

* Attaques Bucket brigade
* Attaques par rejeu
* Attaques de falsification de requête intersites (CSRF ou XSRF)
* Attaques par force brute
* <Tooltip tip="Suspicious IP Throttling : forme de protection contre les attaques qui protège votre tenant contre des connexions suspectes visant un trop grand nombre de comptes à partir d’une seule adresse IP." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Suspicious+IP+throttling">Suspicious IP throttling</Tooltip>
* Attaques de credential stuffing
* Attaques de validation de liste

Auth0 offre des [fonctionnalités de protection contre les attaques](/docs/fr-ca/secure/attack-protection) qui peuvent aider à contrer certains types d’attaques.

<div id="bucket-brigade-attacks">
  ## Attaques Bucket brigade
</div>

Un type de menace est l’attaque Bucket brigade, parfois appelée attaque « man-in-the-middle », où l’attaquant s’interpose entre deux parties. Chaque partie croit interagir au moyen d’une connexion privée, alors que l’échange est en réalité contrôlé par l’attaquant tiers. Pour que ce type d’attaque réussisse, l’attaquant doit établir une authentification mutuelle entre les deux parties.

Habituellement, les attaques Bucket brigade impliquent que l’attaquant utilise un routeur WiFi pour intercepter les communications d’un utilisateur. L’utilisateur se connecte au routeur de l’attaquant, puis visite un site Web et s’y connecte à l’aide de ses identifiants confidentiels. L’attaquant enregistre alors les identifiants de connexion de cet utilisateur, qu’il peut ensuite utiliser pour se faire passer pour lui.

Certaines attaques Bucket brigade peuvent aussi modifier les données transmises entre l’application et le serveur. Des attaques peuvent survenir en raison de nouveaux PC d’essai et de logiciels préinstallés, d’outils de mise à jour logicielle et d’autres vulnérabilités logicielles. Dans le pire des cas, cela pourrait entraîner l’exécution de code à distance, l’installation de portes dérobées dans le système, l’installation de logiciels malveillants, et ainsi de suite. Cela pourrait aussi mener à la compromission d’autres ressources réseau.

Pour aider à se défendre contre ce type d’attaque, il est important d’utiliser un chiffrement robuste et une authentification entre l’application et le serveur. Grâce au chiffrement, le serveur authentifie la requête de l’application en présentant un certificat numérique, et ce n’est qu’ensuite que la connexion peut être établie. Par exemple, HTTPS utilise la fonctionnalité de couche de sockets sécurisés (SSL) du navigateur pour masquer le trafic Web. Pour déchiffrer HTTPS, un attaquant devrait obtenir les clés utilisées pour chiffrer le trafic réseau.

Pour configurer TLS sur vos serveurs, nous vous suggérons d’utiliser les [recommandations OpSec de Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS), qui utilisent TLSv1.2. Mozilla fournit aussi un [générateur de configuration SSL](https://mozilla.github.io/server-side-tls/ssl-config-generator/) ; pour l’utiliser, choisissez d’abord la plateforme sur laquelle votre serveur fonctionne, puis la configuration la plus moderne que votre parc d’applications peut prendre en charge. Les configurations les plus modernes offrent des algorithmes de chiffrement plus robustes pour aider à prévenir les attaques.

<div id="replay-attacks">
  ## Attaques par rejeu
</div>

Les attaques par rejeu (ou attaques de relecture) permettent aux attaquants de :

* Obtenir accès à un réseau et à des informations qui n’auraient pas été facilement accessibles autrement
* Exécuter une transaction en double

Il s’agit d’attaques visant le protocole de sécurité, dans lesquelles des données transmises par un autre émetteur sont rejouées vers le système récepteur visé. Ces attaques amènent les participants à croire que la transmission des données a été effectuée avec succès.

Les attaques par rejeu peuvent être évitées à l’aide de jetons de session. Toutefois, si ces informations d’identification sont volées à partir du stockage local (par exemple lors d’une attaque XSS), il existe des moyens d’empêcher quelqu’un de conserver indéfiniment un jeton valide :

* Définir une courte durée d’expiration pour les jetons
* Prévoir un moyen d’ajouter à la DenyList les jetons qui ont été utilisés (et possiblement même les utilisateurs)
* Utiliser des mots de passe à usage unique

La spécification [JWT](/docs/fr-ca/secure/tokens/json-web-tokens) fournit le champ `jti` comme moyen de prévenir les attaques par rejeu. Bien que les jetons Auth0 ne renvoient pas actuellement le `jti`, vous pouvez ajouter des jetons à la DenyList à l’aide du `jti` pour empêcher qu’un jeton soit utilisé plus d’un certain nombre de fois. De cette façon, vous mettez en œuvre quelque chose de semblable à un <Tooltip tip="Nonce : Nombre arbitraire émis une seule fois dans un protocole d’authentification pour détecter et prévenir les attaques par rejeu." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=nonce">nonce</Tooltip> (considérez la signature du jeton comme le nonce). Si un jeton est volé ou s’il est utilisé plus souvent que le nombre de fois permis, il devrait être ajouté à la DenyList. Cela empêche l’utilisation malveillante d’un jeton valide. Une fois le jeton expiré, l’attaquant ne pourra plus usurper l’identité de l’utilisateur.

Vous pouvez aussi éviter les attaques par rejeu en utilisant des mots de passe à usage unique. Avec Auth0, vous pouvez utiliser l’authentification <Tooltip tip="Passwordless : Forme d’authentification qui ne repose pas sur un mot de passe comme premier facteur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Passwordless">Passwordless</Tooltip>, qui repose sur des codes à usage unique et des liens par courriel plutôt que sur des mots de passe traditionnels. Auth0 offre également l’<Tooltip tip="Authentification multifacteur (MFA) : Processus d’authentification de l’utilisateur qui utilise un facteur en plus du nom d’utilisateur et mot de passe, comme un code envoyé par SMS." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=multi-factor+authentication">authentification multifacteur</Tooltip> (MFA), qui utilise des mots de passe à usage unique comme deuxième facteur d’authentification, pouvant être envoyés par notifications push et par message texte.

<div id="cross-site-request-forgery">
  ## Falsification de requête intersites
</div>

Une attaque de falsification de requête intersites (CSRF ou XSRF) se produit lorsqu’un programme malveillant amène le navigateur Web d’un utilisateur à effectuer une action non souhaitée sur un site de confiance où l’utilisateur est déjà authentifié. Ce type d’attaque cible précisément les requêtes qui modifient l’état afin de déclencher une action, plutôt que d’obtenir des données utilisateur, puisque l’attaquant n’a aucun moyen de voir la réponse à la requête falsifiée.

Une façon de vérifier les requêtes envoyées consiste à utiliser le protocole <Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit les protocoles et les flux de travail d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> [paramètre state](/docs/fr-ca/secure/attack-protection/state-parameters) pour valider la réponse.

<div id="learn-more">
  ## En savoir plus
</div>

* [Jetons](/docs/fr-ca/secure/tokens)
* [Protection contre les attaques](/docs/fr-ca/secure/attack-protection)
* [Conseils de sécurité généraux](/docs/fr-ca/secure/security-guidance/tips)