# XSS (Cross Site Scripting)
## Metodologia
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:
1. In **HTML grezzo**:
1. Puoi creare nuovi tag HTML?
2. Puoi usare eventi o attributi che supportano il protocollo `javascript:`?
3. Puoi bypassare le protezioni?
4. Il contenuto HTML viene interpretato da qualche motore JS lato client (_AngularJS_, _VueJS_, _Mavo_...), potresti abusare di un [**Client Side Template Injection**](../client-side-template-injection-csti.md).
5. Se non puoi creare tag HTML che eseguono codice JS, potresti abusare di un [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html)?
2. Dentro un **tag HTML**:
1. Puoi uscire nel contesto HTML grezzo?
2. Puoi creare nuovi eventi/attributi per eseguire codice JS?
3. L'attributo in cui sei intrappolato supporta l'esecuzione di JS?
4. Puoi bypassare le protezioni?
3. Dentro **codice JavaScript**:
1. Puoi scappare dal tag ``** di una pagina HTML, all'interno di un file `.js` o all'interno di un attributo utilizzando il protocollo **`javascript:`**:
- Se riflesso tra i tag **``**, anche se il tuo input è all'interno di qualsiasi tipo di virgolette, puoi provare a iniettare `` e uscire da questo contesto. Questo funziona perché il **browser prima analizzerà i tag HTML** e poi il contenuto, quindi non si accorgerà che il tuo tag `` iniettato è all'interno del codice HTML.
- Se riflesso **all'interno di una stringa JS** e l'ultimo trucco non funziona, dovresti **uscire** dalla stringa, **eseguire** il tuo codice e **ricostruire** il codice JS (se c'è un errore, non verrà eseguito):
- `'-alert(1)-'`
- `';-alert(1)//`
- `\';alert(1)//`
- Se riflesso all'interno di template literals puoi **inserire espressioni JS** utilizzando la sintassi `${ ... }`: `` var greetings = `Hello, ${alert(1)}` ``
- **La codifica Unicode** funziona per scrivere **codice javascript valido**:
```javascript
alert(1)
alert(1)
alert(1)
```
#### Javascript Hoisting
Javascript Hoisting si riferisce all'opportunità di **dichiarare funzioni, variabili o classi dopo che sono state utilizzate, in modo da poter abusare di scenari in cui un XSS utilizza variabili o funzioni non dichiarate.**\
**Controlla la seguente pagina per ulteriori informazioni:**
{{#ref}}
js-hoisting.md
{{#endref}}
### Javascript Function
Diverse pagine web hanno endpoint che **accettano come parametro il nome della funzione da eseguire**. Un esempio comune da vedere nel mondo reale è qualcosa come: `?callback=callbackFunc`.
Un buon modo per scoprire se qualcosa fornito direttamente dall'utente sta cercando di essere eseguito è **modificare il valore del parametro** (ad esempio in 'Vulnerable') e cercare nella console errori come:
.png>)
Nel caso sia vulnerabile, potresti essere in grado di **attivare un avviso** semplicemente inviando il valore: **`?callback=alert(1)`**. Tuttavia, è molto comune che questi endpoint **validino il contenuto** per consentire solo lettere, numeri, punti e trattini bassi (**`[\w\._]`**).
Tuttavia, anche con quella limitazione è ancora possibile eseguire alcune azioni. Questo perché puoi utilizzare quei caratteri validi per **accedere a qualsiasi elemento nel DOM**:
.png>)
Alcune funzioni utili per questo:
```
firstElementChild
lastElementChild
nextElementSibiling
lastElementSibiling
parentElement
```
Puoi anche provare a **attivare funzioni Javascript** direttamente: `obj.sales.delOrders`.
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)**:
{{#ref}}
some-same-origin-method-execution.md
{{#endref}}
### 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.
{{#ref}}
dom-xss.md
{{#endref}}
### **Universal XSS**
Questi tipi di XSS possono essere trovati **ovunque**. Non dipendono solo dall'esploitazione 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.\
Alcuni **esempi**:
{{#ref}}
server-side-xss-dynamic-pdf.md
{{#endref}}
{{#ref}}
../../network-services-pentesting/pentesting-web/electron-desktop-apps/
{{#endref}}
## WAF bypass encoding image
.jpg>)
## 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 sfruttare `<` 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)**.**\
_**Nota: Un commento HTML può essere chiuso usando\*\*\*\*\*\***\***\*`-->`\*\***\***\*o \*\*\*\*\*\***`--!>`\*\*_
In questo caso e se non viene utilizzato alcun black/whitelisting, potresti usare payload come:
```html