* 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) !
* **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).
Les primes HackenProof ne sont lancées que lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
La **falsification de requête intersite** (également connue sous le nom de CSRF) est une vulnérabilité de sécurité web qui permet à un attaquant d'**induire les utilisateurs à effectuer des actions qu'ils ne souhaitent pas effectuer**.\
Cela est réalisé en **faisant accéder un utilisateur connecté** sur la plateforme victime à un site web contrôlé par l'attaquant et à partir de là, **exécuter** du code JS malveillant, envoyer des formulaires ou récupérer des "images" sur le **compte de la victime**.
Pour pouvoir exploiter une vulnérabilité CSRF, vous devez d'abord **trouver une action pertinente à exploiter** (changer le mot de passe ou l'adresse e-mail, faire en sorte que la victime vous suive sur un réseau social, vous donner plus de privilèges...). La **session doit reposer uniquement sur les cookies ou l'en-tête d'authentification de base HTTP**, aucun autre en-tête ne peut être utilisé pour gérer la session. Enfin, il ne doit pas y avoir de **paramètres imprévisibles** dans la requête.
* [**Cookies SameSite**](hacking-with-cookies/#samesite) : Si le cookie de session utilise ce drapeau, il se peut que vous ne puissiez pas envoyer le cookie à partir de sites web arbitraires.
* [**Partage des ressources entre origines**](cors-bypass.md) : Selon le type de requête HTTP que vous devez effectuer pour exploiter l'action pertinente, vous pouvez prendre en compte la **politique CORS du site victime**. _Notez que la politique CORS n'affectera pas si vous voulez simplement envoyer une requête GET ou une requête POST à partir d'un formulaire et que vous n'avez pas besoin de lire la réponse._
* Demandez le **mot de passe** de l'utilisateur pour autoriser l'action.
* Utilisez un **jeton CSRF** dans chaque session. Ce jeton doit être envoyé dans la requête pour confirmer l'action. Ce jeton peut être protégé par CORS.
Peut-être que le formulaire que vous voulez exploiter est préparé pour envoyer une **requête POST avec un jeton CSRF mais**, vous devriez **vérifier** si un **GET** est également **valide** et si lorsque vous envoyez une requête GET, le **jeton CSRF est toujours validé**.
Certaines applications **valident correctement le jeton lorsqu'il est présent mais ignorent la validation si le jeton est omis**.\
Dans cette situation, l'attaquant peut **supprimer le paramètre entier** contenant le jeton (pas seulement sa valeur) pour contourner la validation et effectuer une attaque CSRF.
Certaines applications ne **vérifient pas que le jeton appartient à la même session** que l'utilisateur qui effectue la requête. Au lieu de cela, l'application **maintient un pool global de jetons** qu'elle a émis et accepte tout jeton qui apparaît dans ce pool.\
Dans cette situation, l'attaquant peut se connecter à l'application en utilisant son propre compte, **obtenir un jeton valide**, puis **transmettre ce jeton à l'utilisateur victime** dans son attaque CSRF.
Par exemple, si elle utilise une méthode **PUT**, vous pouvez essayer d'utiliser une méthode **POST** et **envoyer** : _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Dans une variation ultérieure de la vulnérabilité précédente, certaines applications **dupliquent chaque jeton dans un cookie et un paramètre de requête**. Ou elles **définissent un cookie csrf** et **vérifient en arrière-plan si le jeton csrf envoyé correspond à celui lié au cookie**.
Lorsque la requête suivante est validée, l'application vérifie simplement que le **jeton** soumis dans le **paramètre de requête correspond** à la valeur stockée par le **cookie**.\
Dans cette situation, l'attaquant peut à nouveau effectuer une attaque CSRF **si le site web contient une vulnérabilité qui lui permettrait de définir son cookie CSRF sur la victime comme un CRLF**.
Notez que si le jeton csrf est lié au cookie de session, cette attaque ne fonctionnera pas car vous devrez définir votre session en tant que victime, et vous vous attaquerez donc vous-même.
Selon [**ceci**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), afin d'**éviter les requêtes préliminaires** en utilisant la méthode **POST**, voici les valeurs de Content-Type autorisées :
Cependant, notez que la **logique des serveurs peut varier** en fonction du **Content-Type** utilisé, vous devriez donc essayer les valeurs mentionnées ainsi que d'autres comme **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Comme vous le savez déjà, vous ne pouvez pas envoyer une requête POST avec le Content-Type **`application/json`** via un formulaire HTML, et si vous essayez de le faire via **`XMLHttpRequest`**, une requête de pré-vérification est envoyée en premier.\
Cependant, vous pouvez essayer d'envoyer les données JSON en utilisant les types de contenu **`text/plain`** et **`application/x-www-form-urlencoded`** juste pour vérifier si le backend utilise les données indépendamment du Content-Type.\
Vous pouvez envoyer un formulaire en utilisant `Content-Type: text/plain` en définissant **`enctype="text/plain"`**
Si le serveur n'accepte que le type de contenu "application/json", vous pouvez **envoyer le type de contenu "text/plain; application/json"** sans déclencher de requête de pré-vérification.
Vous pouvez également essayer de **contourner** cette restriction en utilisant un fichier flash SWF. Pour plus d'informations, [**lisez cet article**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
La première partie de [**ce compte rendu CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explique que [le code source d'Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), un routeur est configuré pour **traiter les requêtes HEAD comme des requêtes GET** sans corps de réponse - une solution de contournement courante qui n'est pas propre à Oak. Au lieu d'un gestionnaire spécifique pour les requêtes HEAD, elles sont simplement **transmises au gestionnaire GET mais l'application supprime simplement le corps de réponse**.
Si un **jeton CSRF** est utilisé comme **défense**, vous pouvez essayer de **l'exfiltrer** en exploitant une vulnérabilité [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou une vulnérabilité [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
A common method used by web applications to send data to the server is through a form POST request. This type of request is commonly used for actions such as submitting a login form or submitting a contact form.
Une méthode couramment utilisée par les applications web pour envoyer des données au serveur est la requête POST de formulaire. Ce type de requête est généralement utilisé pour des actions telles que la soumission d'un formulaire de connexion ou la soumission d'un formulaire de contact.
One common technique used in Cross-Site Request Forgery (CSRF) attacks is to submit a form through an iframe. This technique allows an attacker to trick a user into unknowingly submitting a form on a vulnerable website.
To perform this attack, the attacker first creates a malicious webpage that contains an iframe pointing to the target website's form. The attacker then lures the victim into visiting the malicious webpage.
When the victim visits the malicious webpage, the iframe automatically submits the form on the target website, using the victim's authenticated session. Since the victim is already logged in to the target website, the form submission appears legitimate.
This technique can be particularly effective when combined with social engineering tactics, such as sending the victim a link to the malicious webpage via email or a messaging platform.
- Implementing anti-CSRF tokens: By including a unique token in each form, developers can ensure that the form submission originated from their website and not from an external source.
- Implementing SameSite cookies: By setting the SameSite attribute to "Strict" or "Lax" for cookies, developers can prevent them from being sent in cross-origin requests, effectively mitigating CSRF attacks.
- Implementing strict referrer policies: By setting the referrer policy to "strict-origin-when-cross-origin" or "same-origin", developers can control how much information is included in the Referer header, reducing the risk of CSRF attacks.
An Ajax POST request is a type of HTTP request that is sent asynchronously from a web page to a server using the Ajax technology. It allows the web page to update its content dynamically without having to reload the entire page.
Une requête POST Ajax est un type de requête HTTP qui est envoyée de manière asynchrone depuis une page web vers un serveur en utilisant la technologie Ajax. Cela permet à la page web de mettre à jour son contenu de manière dynamique sans avoir à recharger la page entière.
The above code snippet demonstrates an example of an Ajax POST request using jQuery. It sends a POST request to the '/update' endpoint with the data object containing the name and age parameters. If the request is successful, the 'success' callback function is executed, otherwise, the 'error' callback function is executed.
Le code ci-dessus montre un exemple de requête POST Ajax utilisant jQuery. Il envoie une requête POST vers l'endpoint '/update' avec l'objet de données contenant les paramètres name et age. Si la requête est réussie, la fonction de rappel 'success' est exécutée, sinon, la fonction de rappel 'error' est exécutée.
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
When submitting a form on a website, the data is typically sent using the `application/x-www-form-urlencoded` format. However, in some cases, the form may require the use of the `multipart/form-data` format. This format is commonly used when uploading files or when the form contains binary data.
Lors de la soumission d'un formulaire sur un site web, les données sont généralement envoyées au format `application/x-www-form-urlencoded`. Cependant, dans certains cas, le formulaire peut nécessiter l'utilisation du format `multipart/form-data`. Ce format est couramment utilisé lors du téléchargement de fichiers ou lorsque le formulaire contient des données binaires.
To craft a `multipart/form-data` POST request, you need to include a `Content-Type` header with the value `multipart/form-data`. Additionally, the request body should be formatted as a series of parts, each representing a form field or file upload.
Pour créer une requête POST `multipart/form-data`, vous devez inclure un en-tête `Content-Type` avec la valeur `multipart/form-data`. De plus, le corps de la requête doit être formaté comme une série de parties, représentant chacune un champ de formulaire ou un téléchargement de fichier.
Each part consists of a set of headers and a body. The headers specify the name of the form field or file, as well as the content type. The body contains the actual data.
Chaque partie est composée d'un ensemble d'en-têtes et d'un corps. Les en-têtes spécifient le nom du champ de formulaire ou du fichier, ainsi que le type de contenu. Le corps contient les données réelles.
In this example, the request is being sent to `example.com` with a path of `/upload`. The request body consists of two parts: one for the `username` form field and another for the `profile_picture` file upload. The `Content-Disposition` header specifies the name of each part, and the `Content-Type` header specifies the type of content.
Dans cet exemple, la requête est envoyée à `example.com` avec un chemin `/upload`. Le corps de la requête est composé de deux parties : une pour le champ de formulaire `username` et une autre pour le téléchargement du fichier `profile_picture`. L'en-tête `Content-Disposition` spécifie le nom de chaque partie, et l'en-tête `Content-Type` spécifie le type de contenu.
En comprenant comment créer une requête POST `multipart/form-data`, vous pouvez interagir efficacement avec des formulaires web qui nécessitent ce format.
Dans cette technique, nous allons explorer comment effectuer une attaque de type Cross-Site Request Forgery (CSRF) en utilisant une requête POST multipart/form-data.
CSRF is an attack that tricks the victim into submitting a malicious request. It occurs when a malicious website or application forces a user's browser to perform an unwanted action on a trusted website where the user is authenticated.
Le CSRF est une attaque qui trompe la victime en lui faisant soumettre une requête malveillante. Elle se produit lorsque un site web ou une application malveillante force le navigateur de l'utilisateur à effectuer une action non désirée sur un site web de confiance où l'utilisateur est authentifié.
2. Identifier le point d'extrémité cible : Identifiez le point d'extrémité ou l'URL spécifique où l'action que vous souhaitez effectuer est déclenchée.
3. Créer la page HTML malveillante : Créez une page HTML qui contient un formulaire avec les champs nécessaires pour effectuer l'action sur le site web cible.
4. Définir l'attribut action du formulaire sur le point d'extrémité cible : Dans le code HTML du formulaire, définissez l'attribut action sur l'URL du point d'extrémité cible.
6. Définir l'attribut enctype du formulaire sur multipart/form-data : Dans le code HTML du formulaire, définissez l'attribut enctype sur multipart/form-data.
7. Add the necessary form fields: Add the required form fields to perform the action on the target website. These fields should match the expected input of the target endpoint.
7. Ajouter les champs de formulaire nécessaires : Ajoutez les champs de formulaire requis pour effectuer l'action sur le site web cible. Ces champs doivent correspondre à l'entrée attendue par le point d'extrémité cible.
8. Soumettre le formulaire automatiquement : Utilisez JavaScript pour soumettre automatiquement le formulaire lorsque la page HTML malveillante est chargée par le navigateur de la victime.
9. Trick the victim into visiting the malicious HTML page: Send the victim a link or embed the malicious HTML page in a website or email to trick them into visiting it.
9. Tromper la victime pour qu'elle visite la page HTML malveillante : Envoyez à la victime un lien ou intégrez la page HTML malveillante dans un site web ou un e-mail pour la tromper et l'inciter à la visiter.
10. Perform the CSRF attack: When the victim visits the malicious HTML page, their browser will automatically submit the form, triggering the action on the target website.
10. Effectuer l'attaque CSRF : Lorsque la victime visite la page HTML malveillante, son navigateur soumettra automatiquement le formulaire, déclenchant ainsi l'action sur le site web cible.
By exploiting CSRF using a multipart/form-data POST request, an attacker can perform unauthorized actions on a target website, potentially leading to data manipulation, account takeover, or other malicious activities.
En exploitant le CSRF en utilisant une requête POST multipart/form-data, un attaquant peut effectuer des actions non autorisées sur un site web cible, ce qui peut entraîner une manipulation de données, une prise de contrôle de compte ou d'autres activités malveillantes.
In some cases, you may encounter a scenario where you need to submit a form from within an iframe. This can be useful when performing Cross-Site Request Forgery (CSRF) attacks or when testing the security of a web application.
Dans certains cas, vous pouvez rencontrer un scénario où vous devez soumettre un formulaire à partir d'un iframe. Cela peut être utile lors de l'exécution d'attaques de falsification de requête intersite (CSRF) ou lors de la vérification de la sécurité d'une application web.
Pour cela, vous pouvez utiliser JavaScript pour soumettre le formulaire de manière programmée. Voici un exemple de la façon dont vous pouvez y parvenir :
In this example, we have an iframe with the ID "myIframe" that loads a web page from "https://www.example.com". We then use JavaScript to access the iframe's document object and retrieve the form element with the ID "myForm". Finally, we call the `submit()` method on the form to submit it.
Dans cet exemple, nous avons un iframe avec l'ID "myIframe" qui charge une page web à partir de "https://www.example.com". Nous utilisons ensuite JavaScript pour accéder à l'objet document de l'iframe et récupérer l'élément de formulaire avec l'ID "myForm". Enfin, nous appelons la méthode `submit()` sur le formulaire pour le soumettre.
Keep in mind that when performing CSRF attacks, you may need to modify the form's input values to carry out the desired action. Additionally, ensure that you have the necessary permissions and legal authorization before conducting any security testing.
N'oubliez pas que lors de l'exécution d'attaques CSRF, vous devrez peut-être modifier les valeurs d'entrée du formulaire pour effectuer l'action souhaitée. De plus, assurez-vous d'avoir les autorisations nécessaires et l'autorisation légale avant de procéder à des tests de sécurité.
To perform a CSRF attack, the first step is to steal the CSRF token from the target website. This token is usually embedded in the HTML source code or included as a cookie. Once the token is obtained, it can be used to craft a malicious POST request.
Pour effectuer une attaque CSRF, la première étape consiste à voler le jeton CSRF du site cible. Ce jeton est généralement intégré dans le code source HTML ou inclus en tant que cookie. Une fois le jeton obtenu, il peut être utilisé pour créer une requête POST malveillante.
To steal the CSRF token, an attacker can use various techniques such as cross-site scripting (XSS) or social engineering. Once the token is obtained, the attacker can then create a form or script that automatically submits a POST request to the target website.
Pour voler le jeton CSRF, un attaquant peut utiliser différentes techniques telles que le cross-site scripting (XSS) ou l'ingénierie sociale. Une fois le jeton obtenu, l'attaquant peut ensuite créer un formulaire ou un script qui soumet automatiquement une requête POST au site cible.
The POST request can be crafted to perform any action that the target website allows, such as changing account settings, making purchases, or deleting data. By tricking the victim into visiting a malicious website or clicking on a malicious link, the attacker can execute the CSRF attack and perform unauthorized actions on behalf of the victim.
La requête POST peut être créée pour effectuer n'importe quelle action autorisée par le site cible, telle que la modification des paramètres du compte, les achats ou la suppression de données. En trompant la victime pour qu'elle visite un site Web malveillant ou qu'elle clique sur un lien malveillant, l'attaquant peut exécuter l'attaque CSRF et effectuer des actions non autorisées au nom de la victime.
### **Vol de jeton CSRF et envoi d'une requête POST à l'aide d'un iframe, d'un formulaire et d'Ajax**
L'une des méthodes couramment utilisées pour exploiter une vulnérabilité de falsification de requête intersite (CSRF) consiste à voler le jeton CSRF d'un utilisateur légitime et à l'utiliser pour envoyer une requête POST malveillante. Cette attaque peut être réalisée en utilisant un iframe, un formulaire ou Ajax.
Pour voler le jeton CSRF, l'attaquant peut utiliser différentes techniques, telles que l'inclusion de contenu intersite (XSS) ou l'exploitation de vulnérabilités de script côté client. Une fois que l'attaquant a réussi à obtenir le jeton CSRF de l'utilisateur légitime, il peut l'utiliser pour effectuer des actions non autorisées en son nom.
L'attaquant peut utiliser un iframe pour envoyer une requête POST avec le jeton CSRF volé. L'iframe peut être caché ou rendu invisible pour que l'utilisateur ne le remarque pas. L'URL de l'iframe doit être configurée pour envoyer la requête POST à la cible souhaitée, en incluant le jeton CSRF dans les données de la requête.
Une autre méthode consiste à utiliser un formulaire pour envoyer une requête POST avec le jeton CSRF volé. L'attaquant peut créer un formulaire caché et le soumettre automatiquement à l'aide de JavaScript.
L'attaquant peut également utiliser Ajax pour envoyer une requête POST avec le jeton CSRF volé. L'URL de la requête Ajax doit être configurée pour envoyer la requête POST à la cible souhaitée, en incluant le jeton CSRF dans les données de la requête.
Il est important de noter que ces méthodes ne fonctionneront que si l'attaquant a réussi à voler le jeton CSRF de l'utilisateur légitime. Par conséquent, il est essentiel de mettre en place des mesures de sécurité appropriées pour protéger les jetons CSRF et prévenir les attaques CSRF.
To perform a Cross-Site Request Forgery (CSRF) attack, an attacker needs to steal the victim's CSRF token and use it to send unauthorized requests on behalf of the victim. One way to achieve this is by using an iframe and a form.
Pour effectuer une attaque de falsification de requête entre sites (CSRF), un attaquant doit voler le jeton CSRF de la victime et l'utiliser pour envoyer des requêtes non autorisées au nom de la victime. Une façon d'y parvenir est d'utiliser un iframe et un formulaire.
4. Since the form is submitted within the context of the target website, the victim's browser includes the victim's CSRF token in the request, making it appear as a legitimate request.
Étant donné que le formulaire est soumis dans le contexte du site cible, le navigateur de la victime inclut le jeton CSRF de la victime dans la requête, ce qui la rend semblable à une requête légitime.
By exploiting CSRF vulnerabilities, attackers can trick users into unknowingly performing actions on websites they trust. To protect against CSRF attacks, web developers should implement measures such as using CSRF tokens, checking the origin of requests, and implementing strict access controls.
To perform a Cross-Site Request Forgery (CSRF) attack, one common technique is to steal the victim's authentication token and send it using two iframes. This attack takes advantage of the fact that many websites use tokens to authenticate user requests.
1. The attacker creates a malicious webpage that contains two hidden iframes.
2. The first iframe is used to load the target website's login page.
3. The second iframe is used to submit a form with the victim's token to a different URL controlled by the attacker.
4. When the victim visits the malicious webpage, the first iframe loads the login page of the target website. The victim may not notice anything suspicious at this point.
5. The login page contains a hidden form that automatically submits the victim's token to the attacker-controlled URL. This is done using JavaScript code injected into the login page.
6. The second iframe, which is hidden from the victim, captures the victim's token and sends it to the attacker's server.
7. The attacker can then use the stolen token to perform actions on behalf of the victim, such as making unauthorized requests or modifying the victim's account settings.
To protect against this type of attack, website developers should implement measures such as using anti-CSRF tokens, validating the origin of requests, and implementing strict access controls. Additionally, users should be cautious when visiting unfamiliar websites and should log out of websites when they are finished using them.
To perform a Cross-Site Request Forgery (CSRF) attack, an attacker needs to steal the CSRF token from the target website and then use it to send malicious requests on behalf of the victim. One way to achieve this is by using Ajax to steal the token and then sending a POST request using a form.
1. The attacker creates a malicious webpage that contains JavaScript code to perform the CSRF attack.
2. The attacker embeds an invisible iframe on the malicious webpage, pointing to the target website's login page.
3. The attacker's JavaScript code in the malicious webpage uses Ajax to make a GET request to the target website's login page, retrieving the CSRF token from the response.
4. Once the CSRF token is obtained, the attacker's JavaScript code can populate a hidden form with the necessary data for the malicious request.
5. The attacker's JavaScript code then submits the form using a POST request, including the stolen CSRF token in the request headers or body.
6. The target website, considering the request as legitimate due to the presence of the valid CSRF token, processes the malicious request on behalf of the victim.
By using this technique, an attacker can trick the target website into performing actions on behalf of the victim without their knowledge or consent. It is important for web developers to implement proper CSRF protection mechanisms, such as using unique and unpredictable CSRF tokens, to mitigate this type of attack.
Socket.IO est une bibliothèque JavaScript qui permet la communication en temps réel entre le serveur et le client. Lorsqu'il est utilisé de manière incorrecte, Socket.IO peut être vulnérable à une attaque de falsification de requête intersite (CSRF).
#### Qu'est-ce que le CSRF ?
La falsification de requête intersite (CSRF) est une attaque qui exploite la confiance d'un site web dans les requêtes émises par un utilisateur authentifié. L'attaque se produit lorsque le site web ne vérifie pas l'origine de la requête, permettant ainsi à un attaquant de forger une requête en utilisant les informations d'authentification de l'utilisateur.
#### Exploiter le CSRF avec Socket.IO
Pour exploiter le CSRF avec Socket.IO, l'attaquant doit d'abord trouver un point d'injection de code JavaScript sur le site cible. Cela peut être réalisé en exploitant des vulnérabilités telles que les injections de script ou les failles XSS.
Une fois qu'un point d'injection de code JavaScript est trouvé, l'attaquant peut utiliser Socket.IO pour envoyer des requêtes falsifiées au serveur. Ces requêtes peuvent inclure des actions malveillantes telles que la modification des données de l'utilisateur, l'ajout d'un nouvel utilisateur ou la suppression de données sensibles.
Pour prévenir les attaques CSRF avec Socket.IO, il est essentiel de mettre en place des mesures de sécurité appropriées. Voici quelques bonnes pratiques à suivre :
1. Utilisez des jetons anti-CSRF : Générez et utilisez des jetons anti-CSRF uniques pour chaque utilisateur et chaque session. Ces jetons doivent être inclus dans les requêtes Socket.IO et vérifiés côté serveur pour s'assurer de leur validité.
2. Vérifiez l'origine des requêtes : Assurez-vous que les requêtes Socket.IO proviennent bien du site web autorisé. Vous pouvez le faire en vérifiant l'en-tête d'origine (Origin) ou en utilisant des mécanismes de vérification de domaine tels que CORS (Cross-Origin Resource Sharing).
3. Évitez les injections de script et les failles XSS : Assurez-vous que votre application est sécurisée contre les injections de script et les failles XSS en validant et en échappant correctement les données utilisateur.
Le code peut être utilisé pour effectuer une attaque de force brute sur un formulaire de connexion en utilisant un jeton CSRF (il utilise également l'en-tête X-Forwarded-For pour tenter de contourner un éventuel blocage d'adresse IP) :
Les primes HackenProof sont lancées uniquement lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
* Vous travaillez dans une **entreprise de cybersécurité** ? Vous souhaitez voir votre **entreprise annoncée dans HackTricks** ? ou souhaitez-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) !
* **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).
