Se un campo di input accetta% di dati, allora come si può dire che c'è il rischio di XSS memorizzato

Question

Se un campo di input accetta% di dati, allora come si può dire che c'è il rischio di XSS memorizzato

#1 da (2 voti)
#2 da (0 voti)

1

Ho una applicazione ASP.Net Web Forms (aggiornata al 4.0) che ha richieste di convalida su tutte le pagine. Qualcuno che tenta un'iniezione di script (immettendo qualcosa come <script>location.href=dangerurl;</script> in una casella di testo e inviando) genererà un'eccezione poiché la convalida della richiesta ASP.Net non riesce per il controllo di input.

Nelle pagine in cui vengono utilizzati editor HTML (e la convalida della pagina è disattivata) il contenuto di input viene disinfettato utilizzando la libreria antixss.

Tuttavia, quando il sito è stato sottoposto a una revisione esterna, ha sottolineato che queste caselle di testo accettano testo come <% some text e che si ritiene che abbia memorizzato il rischio XSS. La combinazione di caratteri <% è perdonata dal validatore di richieste ASP.Net in qualche modo.

Non riesco a vedere un modo di montare un attacco usando questi caratteri <% . L'osservazione dei valutatori esterni è corretta nel dire che c'è un aumento del rischio XSS e in tal caso come si può creare un vettore XSS?

asp.net web-application xss

posta Lin 14.12.2016 - 23:36

fonte

2 risposte

0

È possibile che il vettore XXS possa essere formato utilizzando diversi metodi di codifica.

esempio:

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

Ecco ulteriori dettagli al riguardo:

link

risposta data 15.12.2016 - 10:26

fonte

Leggi altre domande sui tag asp.net web-application xss

Sulla piattaforma Android, è sicuro utilizzare uno schema URI personalizzato per ricevere una risposta di autorizzazione OAuth 2.0 dalla piattaforma Google Identity? Sicurezza di un contenitore di password nel cloud

score 2 · Accepted Answer

No , la stampa di <% in un contesto HTML non la rende vulnerabile a XSS.

Per un attacco XSS è necessario consentire una lettera dopo la parentesi di apertura, come è stato anche discusso qui . A partire da <% da solo, non puoi costruire un payload HTML. Detto questo, è un po 'sospetto che il filtro XSS non sia andato per tutto il tempo e abbia filtrato le parentesi di apertura seguite dal carattere qualsiasi .

(Eventualmente, gli auditor sono preoccupati per altri vettori di attacco tramite blocchi di codice ASP incorporati ma non è affatto collegato a XSS.)