Questo filtro è abbastanza sicuro da mitigare XSS?

Naviga le tue risposte
1

Ho un'applicazione che sfugge ai seguenti caratteri speciali. 

& < > " '

L'applicazione visualizza pesantemente i parametri di richiesta HTTP in tutta l'applicazione. I parametri della richiesta vengono utilizzati nel corpo HTML, nei tag div, anche all'interno dei tag Javascript <script> . L'unica difesa in questo momento sta sfuggendo a questi 5 caratteri speciali.

Che cosa ho provato fino ad ora?

  1. Leggi il cheat OWASP XSS Prevention e il cheat sheet Bypass del filtro OWASP.
  2. Ho provato a replicare l'applicazione sul mio sistema locale e ho provato a sfocare l'applicazione con i payload XSS.

Le mie domande

  1. Il cheat di OWASP consiglia di eseguire l'escape di & < > " ' / se utilizzato all'interno dei tag HTML. Il filtro della mia applicazione non è in grado di eseguire l'escape solo del carattere / . Credo che / sia necessario solo se l'attributo HTML non è quotato. Ho ragione nel capire questo?

  2. Diciamo, abbiamo il seguente codice HTML all'interno di una pagina JSP. Questo può essere aggirato quando & < > " ' / è sfuggito?
    un. <input type="hidden" name="choice" value="<%= encode(req.getParameter("choice")) %>">
    b. <div> <%= encode(req.getParameter("choice")) %> </div>
    c. <script> document.write("<%= encode(req.getParameter("choice")) %>") </script>

Sono perfettamente consapevole che questo non è sufficiente, ma ho provato un ampio elenco di payload XSS e non sono riuscito a ignorarlo. Escaping questi 5 caratteri all'interno di un contesto HTML mi sembra abbastanza.

Apprezzerei molto se voi poteste esprimere le vostre opinioni su questo. Mi piacerebbe davvero vedere questo filtro aggirato.

    
posta Haunted 26.06.2017 - 23:38
fonte

3 risposte

6

I would really love to see this filter getting bypassed.

Permettimi di essere il primo a soddisfare il tuo desiderio con il payload %0d%0a così sottovalutato e dimenticato:

Il tuo codice: 

<script> 
// TODO
// document.write("<%= encode(req.getParameter("choice")) %>")
</script>

Richiesta: link

Codice risultante: 

<script> 
// TODO
// document.write("
alert(1);//")
</script>

Sebbene si possa pensare che non si possa commentare tale codice, tenere presente che altri sviluppatori potrebbero farlo (per testare / eseguire il debug / disabilitare temporaneamente la funzionalità) senza pensare al buco di sicurezza che potrebbe creare. Per <script> dovresti codificare %0d%0a in \r\n . In ogni caso, non hai bisogno di questa codifica per l'elemento html.

    
risposta data 27.06.2017 - 00:02
fonte
2

Perché non fare affidamento sulla codifica corretta? Un semplice esempio di rottura di una stringa potrebbe essere: 

<script>var a = "<%=encode(a)%>", b="<%=encode(b)%>";</script>

Con un carico utile di a = \ la prima stringa si estenderà all'inizio del secondo e il valore di b sarà al di fuori della stringa. Quindi possiamo usare b = -alert (1)); //

Inoltre stai facendo affidamento sul fatto di non avere attributi html quoteless (ma da 1. Immagino che tu lo sappia).

    
risposta data 27.06.2017 - 08:18
fonte
0

Suggerirei di seguire best practice (invece di fuggire da alcuni caratteri specifici e usare scriptlet che sono una cosa del passato).

Nel tuo caso, dal momento che stai utilizzando JSP, puoi semplicemente utilizzare il tag <c:out /> che renderebbe il tuo codice più leggibile, standard e più sicuro rimuovendo qualsiasi logica di whitelisting personalizzata che potresti aver implementato (dato che al momento sfuggire a 5 caratteri scelti mentre spieghi).

    
risposta data 27.06.2017 - 09:52
fonte

Leggi altre domande sui tag

Prevenzione dei dispositivi che utilizzano lo stesso segreto OTP audit del codice sorgente