Idea più semplice per la protezione dall'XSS riflesso sul lato client

0

Stavo attraversando alcune difese laterali CLIENT contro XSS riflesso, ad es. Auditor XSS (chrome), IE8 XSS Filters, NoScript. Usano l'espressione regolare e altre tecniche sofisticate. Perché non hanno usato un'idea più semplice?

La mia domanda è: perché non memorizziamo ciò che mai andrà al server come parametri e se questi parametri si riflettono nella risposta HTML, allora scartala o codificala. Semplice idea Sento che potrebbero esserci falsi positivi ma non molto convincenti. Qualche input?

    
posta Naman 17.04.2014 - 13:03
fonte

1 risposta

1

My question is- why don't we store what ever is going to server as parameters and if these parameters are reflected in HTML response then discard it or encoded it

Qualche parametro? Quindi, se cerco "Hello" e la pagina di risposta contiene il testo "Ecco i risultati per Hello", viene violata?

Ci deve essere qualche criterio per ciò che conta come potenzialmente pericoloso, altrimenti ogni modulo sul web si romperà in questo modo. Potresti iniziare con "qualsiasi parametro con < in", ma che dire degli attacchi di attributo come onmouseover= o JavaScript injection come '; alert(document.cookie) ? E come fermi un parametro di appena < dalla rottura di ogni tag sulla pagina? Non c'è una risposta a tenuta stagna, ed è per questo che la rilevazione finisce per essere un complesso casino di regole euristiche e non di un modello pulito, a tenuta stagna.

Personalmente ritengo che il rilevamento XSS riflesso lato client sia profondamente fuorviante: in linea di principio destinato al fallimento e in pratica peggio che inutile , ma se lo farai dovrai limitarne l'ambito perché la riflessione del contenuto è una proprietà comune di cui il web ha bisogno per funzionare correttamente, non sempre un attacco.

    
risposta data 17.04.2014 - 14:05
fonte

Leggi altre domande sui tag