Codifica HTML per la protezione contro XSS

(Copiato da la mia risposta su StackOverflow )

No.
HtmlEncode semplicemente NON copre tutti gli attacchi XSS.
La codifica è la soluzione corretta, ma non sempre la codifica HTML - hai bisogno di codifica sensibile al contesto .

Ad esempio, considera javascript lato client generato dal server - il server emette in modo dinamico i valori htmlencoded direttamente nel javascript lato client, htmlencode eseguirà non interrompe script in esecuzione.

Successivamente, considera il seguente pseudocodice:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Ora, nel caso non sia immediatamente ovvio, se Somevar (inviato dall'utente, ovviamente) è impostato ad esempio su

a onclick=alert(document.cookie)

l'output risultante è

<input value=a onclick=alert(document.cookie) id=textbox>

che funzionerebbe chiaramente. Ovviamente, questo può essere (quasi) qualsiasi altro script ... e HtmlEncode non sarebbe di grande aiuto.

Ci sono alcuni vettori aggiuntivi da considerare ... compreso il terzo aroma di XSS, chiamato XSS basato su DOM (in cui lo script dannoso viene generato dinamicamente sul client, ad esempio in base a # valori).

Inoltre, non dimenticare gli attacchi di tipo UTF-7, in cui l'attacco è simile a

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Non c'è molto da codificare lì ...

La soluzione, ovviamente (oltre alla corretta e restrittiva convalida dell'input di white-list), è quella di eseguire la codifica sensibile al contesto : HtmlEncoding è ottimo SE il tuo contesto di output È HTML, o forse tu bisogno di JavaScriptEncoding, VBScriptEncoding o AttributeValueEncoding, o ... ecc.

Se utilizzi MS ASP.NET, puoi utilizzare la loro libreria Anti-XSS, che fornisce tutti i metodi necessari per la codifica del contesto.

Si noti che tutta la codifica non deve essere limitata all'input dell'utente, ma anche valori memorizzati dal database, file di testo, ecc.

Oh, e non dimenticare di impostare esplicitamente il set di caratteri, sia nell'intestazione HTTP che nel tag META, altrimenti avrai ancora vulnerabilità UTF-7 ...

Ultimo punto, relativo allo XSS memorizzato - dato che dovresti eseguire la codifica durante la generazione della pagina, sui dati output , è agevole per quanto riguarda la fonte dei dati, sia da input dell'utente ( ie Reflected XSS) o Database / file (cioè XSS memorizzato / persistente). (Quindi in sostanza sì.)

Altre informazioni e un elenco abbastanza definitivo (non più aggiornato), controlla il Cheat Sheet di RSnake: link

In sostanza, l'XSS si verifica quando un utente malintenzionato riesce a eseguire una specie di script non autorizzato su una pagina Web visualizzata da una potenziale vittima. Quindi, se HtmlEncode i campi prima di stampare sulla pagina Web, la pagina non interpreterà i dati come script. Interpreterà i personaggi come contenuti e il contenuto verrà stampato sulla pagina così com'è.

ad esempio: dì che hai qualcosa di simile

<form action="/printname" >
  <input type="textbox" name="name">
  <input type="submit">
</form>

e sul lato server hai qualcosa come

k=request.GET['name']
return HttpResponse("hai" + k)

se l'utente immette il nome come

<script>alert("hia")</script>

la pagina eseguirà lo script invece di stamparlo. Tuttavia se supponiamo che la funzione HttpResponse HTML codifichi l'output prima di inviarlo al client, < verrà sostituito da < e > sarà sostituito da > e le virgolette doppie saranno sostituite da " .

Il risultato sarebbe la pagina che interpreta l'output come contenuto anziché come script.

Spero che la mia risposta sia chiara. E aiuta a prevenire l'XSS memorizzato, perché il valore memorizzato è codificato prima della stampa.