Quali sono i diversi payload utilizzati per la vulnerabilità XSS? [chiuso]

Guardando questo payload da solo, senza il resto del codice, è probabilmente difficile capirlo.

Diciamo che c'è un codice JS e PHP in un sito web:

<script>
var jsvar;
jsvar = "<?php echo $phpvar;?>";
</script> 

Ciò che questo codice fa è semplicemente assegnare una variabile controllata dall'utente da PHP alla variabile JS jsvar. Se la variabile PHP contiene il testo test , la variabile JS diventerà:

jsvar="test";

Se l'utente inserisse solo alert() nella variabile PHP, la variabile JS diventerebbe:

jsvar="alert()";

... che non causerebbe XSS perché alert () sarebbe solo una stringa.

Ma se l'utente / utente malintenzionato inserisce \";alert('XSS');// , il codice JS diventerebbe:

jsvar = "";alert('XSS');//";

Qui puoi vedere che l'attaccante ha assegnato "" alla variabile jsvar e come comando successivo ha inserito alert('XSS'); . Il // alla fine è solo per commentare il resto della linea. E il segno \ all'inizio del payload era solo per sfuggire al segno " in PHP, quindi è considerato come testo in PHP.

Dipende dal contesto. Quali sono i 5 tipi di base:

1. contesto HTML

Nel corpo di un tag HTML esistente o all'inizio e alla fine della pagina al di fuori del tag.

<some_html_tag> user_input </some_html_tag>

In questo contesto puoi inserire qualsiasi tipo di codice HTML valido nell'input dell'utente e verrà immediatamente visualizzato dal browser, il suo contesto eseguibile.

Ad esempio: <img src=x onerror=alert(1)>

2. Contesto nome attributo

All'interno del tag HTML di apertura, dopo il nome del tag o dopo un valore di attributo.

<some_html_tag user_input some_attribute_name="some_attribute_value"/>

In questo contesto puoi inserire un nome di gestore di eventi e codice JavaScript seguendo un simbolo = e possiamo avere l'esecuzione di codice, può essere considerato un contesto eseguibile.

Ad esempio: onclick="alert(1)"

3. Contesto valore attributo

All'interno del tag HTML di apertura, dopo che il nome di un attributo è stato separato da un simbolo =.

<some_html_tag some_attribute_name="user_input" />
<some_html_tag some_attribute_name='user_input' />
<some_html_tag some_attribute_name=user_input />

Esistono tre varianti di questo contesto: - Attributo doppio citato - Attributo singolo quotato - Cita meno attributi

L'esecuzione di codice in questo contesto dipenderà dal tipo di attributo in cui appare l'input. Esistono diversi tipi di attributi:

a) Attributi evento

Questi sono attributi come onclick, onload ecc. ei valori di questi attributi sono eseguiti come JavaScript. Quindi qui tutto è uguale al contesto JavaScript.

b) Attributi URL

Questi sono attributi che accettano l'URL come valore, ad esempio l'attributo src di tag diversi. Inserire qui un URL JavaScript potrebbe portare all'esecuzione di JavaScript

Ad esempio: javascript:some_javascript()

c) Attributi URL speciali

Questi sono attributi URL in cui l'inserimento di un URL normale può portare a problemi di sicurezza. Alcuni esempi sono:

<script src="user_input"
<iframe src="user_input"
<frame src="user_input"
<link href="user_input"
<object data="user_input"
<embed src="user_input"
<form action="user_input"
<button formaction="user_input"
<base href="user_input"
<a href="user_input"

L'immissione di un URL http o https assoluto in questi casi potrebbe influire sulla sicurezza del sito web. In alcuni casi, se è possibile caricare dati controllati dall'utente sul server, anche l'inserimento di URL relativi potrebbe causare un problema. Alcuni siti potrebbero rimuovere http: // e https: // dai valori immessi in questi attributi per impedire l'inserimento di URL assoluti, ma esistono molti modi in cui è possibile specificare un URL assoluto.

d) Attributi del tag META

I meta tag come Charset possono influenzare il modo in cui il contenuto della pagina viene interpretato dal browser. E poi c'è l'attributo http-equiv, può emulare il comportamento delle intestazioni di risposta HTTP. Influenzare i valori di intestazioni come Content-Type, Set-Cookie ecc. Avrà un impatto sulla sicurezza della pagina.

e) Attributi normali

Se l'input viene visualizzato in un valore di attributo normale, questo contesto deve essere sottoposto a escape per condurre all'esecuzione del codice. Se l'attributo è quotato, la citazione corrispondente deve essere utilizzata per evitare il contesto. In caso di attributi non quotati, lo spazio o il backslash dovrebbero essere eseguiti. Una volta fuori da questo contesto, è possibile aggiungere un nuovo gestore di eventi per condurre all'esecuzione del codice.

Esempio:

" onclick=alert(1)
' onclick=alert(1)
 onclick=alert(1)

4. Contesto commenti HTML

All'interno della sezione commenti di HTML

<!-- some_comment  user_input some_comment -->

Questo è un contesto non eseguibile ed è richiesto di uscire da questo contesto per eseguire il codice. Inserire un - > chiuderebbe questo contesto e passerebbe qualsiasi testo successivo al contesto HTML.

Ad esempio: --><img src=x onerror=alert(1)>

5. Contesto JavaScript

All'interno delle parti del codice JavaScript della pagina.

<script>
some_javascript
user_input
some_javascript
</script>

Questo si applica alla sezione racchiusa dai tag SCRIPT, nei valori degli attributi del gestore eventi e negli URL che precedono con javascript:.

L'input dell'utente all'interno di JavaScript potrebbe apparire nei seguenti contesti:

a) Contesto del codice b) Contesto stringa quotato singolo c) Contesto di stringhe con doppia quotatura d) Contesto di commento a riga singola e) Contesto di commenti su più righe f) Stringhe assegnate ai sink eseguibili

Se l'input dell'utente si trova tra i tag SCRIPT, non importa in quale dei suddetti contesti appaia, puoi passare al contesto HTML semplicemente includendo un tag SCRIPT di chiusura e quindi inserire qualsiasi HTML.

Ad esempio: </script><img src=x onerror=alert(1)>

Gli altri miscellenosi sono i contesti VBScript e CSS che non sono molto usati. Ma questi potrebbero essere usati dagli script di context context (scanner, sia statici che dinamici) per rilevare potenziali XSS (usati in Burp Engine).

Sarei leggermente in disaccordo con la risposta di @pineapplemans.

Se usiamo il loro codice di esempio con l'input dell'utente:

<?php $phpvar = $_GET['f']; ?>
<script>
var jsvar;
jsvar = "<?php echo $phpvar;?>";
</script> 

Quindi il payload \";alert('XSS');// non verrebbe eseguito. Questo perché la stringa di attacco non si trova direttamente all'interno del codice PHP, quindi non è necessaria alcuna escape. Piuttosto, l'escape sfugge al " che dovrebbe chiudere la stringa, il che significa che il carico utile verrà interpretato come stringa, non come codice JavaScript.

Un payload di lavoro per questo esempio di codice sarebbe ";alert('XSS');// , senza \ .

Escaping the Escape

Il mio presupposto sarebbe che il carico utile \";alert('XSS');// sia inteso per le situazioni in cui " è scappato come \" , ma \ stesso non è sfuggito.

Il codice di esempio sarebbe il codice sopra, con $phpvar = str_replace("\"", "\\"", $phpvar); inserito.

Questo darebbe un attacker jsvar = "\";alert('XSS');//"; , che verrebbe eseguito, dato che il% co_de iniettato sfugge al \ che viene aggiunto per uscire dal% co_de injected.