XSS riflesso tramite JSON eseguito con Burp, ma come farlo in condizioni realistiche?

3

Sto testando uno scenario con il proxy Burp.

  1. Mi trovo su un sito web https://website.com/web

  2. C'è un'opzione per eliminare un elemento, quando fai clic su di esso, viene inviata una certa richiesta POST ( XMLHttpRequest , non avviene alcun aggiornamento della pagina) dove posso inserire un tag <script> :

    POST /web/deleteItem HTTP/1.1
    Host: website.com
    
    returnParameter=<script>alert('xss')</script>
    
  3. Il metodo

    deleteItem restituisce quanto segue:

    HTTP/1.1 200 OK
    Date: Tue, 31 Jan 2017 22:18:54 GMT
    X-XSS-Protection: 1; mode=block
    Content-Type: application/json;charset=UTF-8
    ...
    
    {"status":"SUCCESS","result":"<script>alert('xss')</script>"}
    
  4. In un sito Web del passaggio 1 esistono funzioni JavaScript che analizzano il JSON e mostrano il suo valore di risultato sullo schermo

  5. alert viene mostrato su https://website.com/web , quindi XSS riflesso è stato eseguito correttamente.

Ma questo scenario non è realistico in quanto ho bisogno di disegnare un utente sul sito Web ed eseguire l'XSS in qualche modo.

Ho provato questo facendo un semplice modulo HTML POST e inviando i parametri a https://website.com/web/deleteItem . Diciamo che userò il phishing e che l'utente invierà il modulo.

L'azione è stata effettivamente eseguita, ma ho ricevuto solo una risposta JSON . Non c'era nessuna pagina del passaggio n. 1, quindi non veniva mostrato nulla come XSS, perché l'utente non si trovava su https://website.com/web dove dovrebbe essere eseguito alert('XSS') . Non sono sicuro che sia possibile inviare l'utente alla pagina n. 1 e inviarlo questo JSON con XSS in qualche modo.

Potrebbe esserci un modo per eseguire questo scenario in condizioni realistiche?

    
posta fing 01.02.2017 - 00:39
fonte

1 risposta

2

La vulnerabilità XSS riflessa proposta è completamente e totalmente non utilizzabile dai browser moderni a causa del seguente tipo di contenuto:

Content-Type: application/json;charset=UTF-8

Il tipo di contenuto deve essere HTML, o un tipo di contenuto mancante farebbe il trucco. Avere un'applicazione content-type / json o plain / text sono entrambi forti attenuanti contro XSS.

Lo sniffing dei contenuti può essere utilizzato dai vecchi browser per eseguire JavaScript nonostante il contenuto definito -genere. Come attaccante, se il browser di destinazione utilizza ancora lo sniffing del contenuto, il browser è vulnerabile anche a bug peggiori, come l'esecuzione di codice in modalità remota drive-by.

Come sottolineato da @Jeroen, si tratta di un problema di convalida dell'input non sicuro e, anche se potrebbe non essere vulnerabile a XSS riflessivo, potrebbe portare ad altri problemi come le iniezioni di codice del 2 ° ordine e XSS persistente.

    
risposta data 01.02.2017 - 01:05
fonte

Leggi altre domande sui tag