payload XSS con una restrizione di dieci caratteri

3

C'è un campo di input che non viene codificato sul lato server. Ma se dai un intero script diciamo <img src=a onerror=alert(1)> , mostra un errore del tipo: <img src=a....' non è un valore valido.

Non sono a conoscenza di alcun payload che sia abbastanza corto per sfruttarlo.

  • È possibile eseguire un attacco XSS?
  • In caso negativo, come devo segnalare questa vulnerabilità al proprietario dell'applicazione?
posta one 18.06.2016 - 21:45
fonte

2 risposte

5

Is carrying out an XSS attack possible?

No, 10 caratteri non sono sufficienti per sfruttarlo. Se vuoi inserire un contesto JavaScript, come minimo, avresti bisogno di:

  • 1 < entrare in un contesto di tag
  • 1+ [a-z] per il nome del tag
  • 1 spazio
  • 1+ [a-z] per l'attributo (in pratica, l'attributo evento più breve attualmente esistente è onload, che è di 6 caratteri)
  • 1 =
  • il tuo payload

Ciò significa che anche in una situazione ideale, hai solo 5 caratteri per il tuo carico utile. Anche se qualcosa come jQuery è già caricato, il caricamento di uno script remoto richiede più caratteri.

In realtà, non hai nemmeno 5 caratteri. L'attributo più corto è di 6 caratteri, ma l'onload non funziona con img senza un src valido, quindi onerror è più breve, dandoti <img onerror=[] src=a> (20 caratteri). Con un tag body, puoi ridurlo un po ': <body onload=[]> (14 caratteri), che è ancora troppo lungo. E hai ancora bisogno del tuo payload, che sarà un minimo di ~ 25 caratteri (es. $.getScript('http://x.c') ).

Ciò significa che nella tua situazione, i tag script sarebbero in realtà i più brevi. Ma si arriva solo a <script sr con 10 caratteri.

Non puoi nemmeno iniettare un link, che potrebbe essere usato per il phishing, come anche un tag è tagliato: <a href=ht

If not, how should I report this vulnerability to the application owner?

La lunghezza del testo è configurabile? In tal caso, ciò rappresenterebbe comunque una vulnerabilità valida.

Se non è configurabile, non lo considererei una vulnerabilità sfruttabile, ma lo segnalerei comunque (almeno se li contatto comunque a causa di ulteriori problemi), in quanto potrebbe diventare un problema in futuro in caso il venditore decida di mostrare più caratteri.

    
risposta data 18.06.2016 - 23:10
fonte
3

Dipenderà, ma se c'è un altro posto in cui è inserito l'input dell'utente, questi 10 caratteri sarebbero sufficienti per ingannare il browser per analizzarlo in un altro contesto.

Supponiamo che ci sia sotto un'immagine (ad esempio un avatar) che può essere controllata da un utente malintenzionato, incluso il testo alternativo. Un utente malintenzionato può impostare:

<img src="myimage.jpg" alt="--><script>alert(1);</script>" />

Sarebbe sicuro non codificare questo alt text, poiché appare solo in un parametro.

Tuttavia, se il testo non codificato nel messaggio di errore era " <!-- ", allora tutto fino a --> nel parametro viene considerato come un commento e l'alert () viene eseguito.

Un'altra opzione sarebbe un testo non filtrato come « <b c=" », sebbene il resto del carico utile dovrebbe essere molto più vicino.

Il parametro potrebbe essere qualsiasi cosa (ad esempio l'URL dell'immagine), per quanto l'escape "ridondante" non è stato eseguito su di esso, e appare dopo il testo non filtrato (lo sfruttamento effettivo dipenderà dai tag tra parentesi).

    
risposta data 19.06.2016 - 00:24
fonte

Leggi altre domande sui tag