XSS non sfruttabile quando i dati POST vengono inviati in JSON?

Question

XSS non sfruttabile quando i dati POST vengono inviati in JSON?

#1 da (-1 voti)

3

C'è un difetto XSS riflesso in un'applicazione che sto testando. Inizialmente, il carico utile viene inviato nella richiesta POST come valore di una chiave JSON e la risposta è anche un oggetto JSON. Il valore restituito nell'oggetto JSON viene utilizzato direttamente dal lato client Javascript e quindi dal difetto. Le mie domande sono, ho provato tutti i modi dati su questa pagina per inviare un carico utile JSON tramite modulo HTML ma non sono riuscito poiché il server sta validando correttamente l'input. C'è un modo in cui questo difetto XSS può essere sfruttato? Inoltre, il metodo GET sullo stesso URL non funziona.

json web-application xss

posta entropy 16.06.2016 - 15:57

fonte

1 risposta

Leggi altre domande sui tag json web-application xss

i dati cancellati vengono immediatamente sovrascritti con i nuovi dati nei dischi rigidi Esiste un modo per ottenere la password dell'utente corrente in Windows 10?

score -1 · Answer 1

L'articolo sta dimostrando che un modulo HTML può essere utilizzato per inviare un oggetto JSON tramite CSRF, anche se il lato server accetta solo text/plain richieste che prevedono JSON.
(invece delle tipiche application/x-www-form-urlencoded ) richieste.

Ho incluso l'esempio collegato su questo sito, perché non ammettiamo contenuti di solo collegamento.

<html>  
<form action=http://192.168.1.41:3000 method=post enctype="text/plain" >  
<input name='{"a":1,"b":{"c":3}, "ignore_me":"' value='test"}'type='hidden'>  
<input type=submit>  
</form>  
</html>

genera una richiesta simile a

Inbaseaituoicommenti,oracapiscochestaichiedendodiattacchiReflectedXSS.

ThepayloadisreturnedunchangedinaJSONresponse.

C'èqualcheHTMLcoinvolto?
Seècosì,tuttodipendedacomeècodificatosehaiunavulnerabilitàXSS.

D'altraparte,sequestoèsemplicementeun"eco" senza HTML aggiunto, dipende dalle intestazioni di risposta. Content-Type: text/html dovrebbe essere sufficiente per mantenere la risposta dall'esecuzione come codice, ma in alcuni browser, sarebbe comunque vulnerabile . Content-Disposition: attachment risolverebbe il problema presumendo che l'estensione filename e i tipi di contenuto siano sicuri. (cioè txt )

if the payload can't be sent via HTML forms, does that mean XSS is not "exploitable" ?

if one can't create an HTML form (with JSON payload which is accepted by server) , then this XSS is not exploitable right ?

Tuttavia, con una domanda del genere, sembra che tu stia per "spararti nel piede" bloccando una risposta "facile". Sono preoccupato solo perché non capisco perché stai facendo questa domanda .

Avviso: con un modulo HTML potrebbe essere possibile inviare il payload JSON richiesto in base alle specifiche della convalida del server che stai utilizzando.

Ti risponderò comunque: Supponendo che un modulo HTML non sia sufficiente (il che significa che hai già smentito il mio avviso) e anche Query String non è sufficiente (true nel tuo caso); quindi gli attacchi Reflective XSS non sarebbero possibili.

L'attaccante verrebbe lasciato solo con AJAX come possibilità, così come vari plugin che potrebbero essere in grado di avviare CSRF . XSS memorizzato potrebbe essere ancora possibile in quella situazione, se il tuo server ha funzioni più avanzate oltre a "echo" della richiesta.

Ulteriori informazioni:

Ci sono tre strade che vengono in mente per XSS. Solo gli articoli 2 e 3 richiedono il 'carico utile di tua scelta' per essere caricati tramite CSRF.

Gli articoli 1 e 2 si applicano a un attacco XSS memorizzato che implica l'inserimento di codice in uno dei campi di testo del database del server, in modo tale che quando il server mostra i risultati successivamente potrebbe essere eseguito nel Browser a causa della codifica mancante / errata (vulnerabilità XSS) da parte del server.

Se disponi di credenziali appropriate, o se è un sito pubblico di fronte (ad esempio, i commenti Stack Archive), allora chiunque (anche l'autore dell'attacco) può inserire direttamente il codice.

Quindi se il sistema fosse vulnerabile (codifica errata / mancante), i futuri visitatori che visionano il contenuto inviato sarebbero vittime dell'attacco.
Se si tratta di un sistema chiuso, in modo tale che l'utente malintenzionato non disponga delle credenziali di accesso appropriate per i dati inviati da accettare in un database, l'utente malintenzionato dovrebbe utilizzare un CSRF per trarre vantaggio delle credenziali di un altro utente (supponendo che l'utente sia già connesso al sistema di destinazione quando visita il sito dell'attacker)
Per XSS riflettente , per questo è necessario il # 2 CSRF. In questo caso i dati non devono essere memorizzati, ma stai sfruttando una situazione in cui i dati di input vengono restituiti all'utente.
- vale a dire. una pagina di anteprima,
- o una forma aggiornata con valori precompilati
- una pagina di errore che include il contenuto dell'utente (ad esempio X è un indirizzo email non valido)

L'XSS memorizzato può essere preferibile perché l'attaccante raggiunga un pubblico più ampio. C'è anche la possibilità che un determinato sistema non sia vulnerabile a XSS memorizzato, ma potrebbe comunque essere vulnerabile a Reflective XSS.