La codifica HTML previene tutti i tipi di attacchi XSS?

https://stackoverflow.com/questions/53728

09-06-2019
|

Domanda

Non sono preoccupato per altri tipi di attacchi.Voglio solo sapere se HTML Encode può prevenire tutti i tipi di attacchi XSS.

Esiste un modo per eseguire un attacco XSS anche se viene utilizzata la codifica HTML?

Soluzione

NO.

Mettendo da parte l'argomento relativo all'autorizzazione di alcuni tag (non proprio il punto della domanda), HtmlEncode semplicemente NON copre tutti gli attacchi XSS.

Ad esempio, considera il javascript lato client generato dal server: il server genera dinamicamente valori codificati in html direttamente nel javascript lato client, htmlencode lo farà non fermarti script iniettato dall'esecuzione.

Successivamente, considera il seguente pseudocodice:

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

Ora, nel caso in cui 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 aiuterebbe molto.

Ci sono alcuni vettori aggiuntivi da considerare...inclusa la terza versione di XSS, chiamata XSS basata su DOM (in cui lo script dannoso viene generato dinamicamente sul client, ad es.in base a # valori).

Inoltre, non dimenticare gli attacchi di tipo UTF-7, ovvero l'aspetto dell'attacco

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

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

La soluzione, ovviamente (oltre alla corretta e restrittiva convalida degli input nella white list), è eseguire sensibile al contesto codifica:HtmlEncoding è ottimo SE il tuo contesto di output è HTML, o forse hai bisogno di JavaScriptEncoding, o VBScriptEncoding, o AttributeValueEncoding, o...eccetera.

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

Tieni presente che tutta la codifica non dovrebbe essere limitata all'input dell'utente, ma anche ai 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...

Qualche informazione in più e un elenco abbastanza definitivo (costantemente aggiornato), controlla il Cheat Sheet di RSnake: http://ha.ckers.org/xss.html

Altri suggerimenti

Se codifichi sistematicamente tutti gli input dell'utente prima della visualizzazione ~~allora sì, sei al sicuro~~ non sei ancora sicuro al 100%.
(Vedi il post di @Avid per maggiori dettagli)

Inoltre sorgono problemi quando è necessario affittare Alcuni i tag non vengono codificati in modo da consentire agli utenti di pubblicare immagini o testo in grassetto o qualsiasi funzionalità che richieda che l'input dell'utente venga elaborato come (o convertito in) markup non codificato.

Dovrai impostare un sistema decisionale per decidere quali tag sono consentiti e quali no, ed è sempre possibile che qualcuno trovi un modo per consentire il passaggio di un tag non consentito.

Aiuta se segui il consiglio di Joel di Far sembrare sbagliato il codice sbagliato o se la tua lingua ti aiuta avvisando/non compilando quando si emettono dati utente non elaborati (digitazione statica).

Se codifichi tutto, lo farà.(a seconda della piattaforma e dell'implementazione di htmlencode) Ma qualsiasi applicazione web utile è così complessa che è facile dimenticare di controllarne ogni parte.O forse un componente di terze parti non è sicuro.O forse qualche percorso di codice che pensavi di codificare non lo ha fatto, quindi l'hai dimenticato da qualche altra parte.

Quindi potresti voler controllare anche le cose sul lato input.E potresti voler controllare le cose che leggi dal database.

Come menzionato da tutti gli altri, sei al sicuro finché codifichi Tutto input dell'utente prima di visualizzarlo.Ciò include tutti i parametri della richiesta e i dati recuperati dal database che possono essere modificati tramite input dell'utente.

COME menzionato dal Pat a volte vorrai visualizzare alcuni tag, ma non tutti i tag.Un modo comune per farlo è utilizzare un linguaggio di markup come Tessile, Ribasso, O Codice BBC.Tuttavia, anche i linguaggi di markup possono essere vulnerabili agli XSS, fai solo attenzione.

# Markup example
[foo](javascript:alert\('bar'\);)

Se decidi di lasciare passare i tag "sicuri", ti consiglio di trovare qualche libreria esistente per analizzare e disinfettare il tuo codice prima dell'output.Ci sono molti vettori XSS là fuori che dovresti rilevare prima che il tuo disinfettante sia abbastanza sicuro.

Secondo il consiglio di Metavida di trovare una libreria di terze parti per gestire il filtraggio dell'output.Neutralizzare i caratteri HTML è un buon approccio per fermare gli attacchi XSS.Tuttavia, il codice utilizzato per trasformare i metacaratteri può essere vulnerabile agli attacchi di evasione;ad esempio, se non gestisce correttamente Unicode e internazionalizzazione.

Un classico e semplice errore commesso dai filtri di output homebrew è quello di catturare solo < e >, ma perdere cose come ", che può suddividere l'output controllato dall'utente nello spazio degli attributi di un tag HTML, dove Javascript può essere collegato al DOM.

No, la semplice codifica dei token HTML comuni NON protegge completamente il tuo sito dagli attacchi XSS.Vedi, ad esempio, questa vulnerabilità XSS trovata su google.com:

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

La cosa importante di questo tipo di vulnerabilità è che l'aggressore è in grado di codificare il suo payload XSS utilizzando UTF-7 e, se non hai specificato una codifica di caratteri diversa sulla tua pagina, il browser di un utente potrebbe interpretare il payload UTF-7 e eseguire lo script di attacco.

Un'altra cosa che devi controllare è da dove proviene il tuo input.Puoi utilizzare la stringa del referrer (la maggior parte delle volte) per verificare che provenga dalla tua stessa pagina, ma inserire un numero casuale nascosto o qualcosa del genere nel modulo e poi controllarlo (magari con una variabile impostata sulla sessione) aiuta anche a sapere che il l'input proviene dal tuo sito e non da qualche sito di phishing.

Vorrei suggerire il purificatore HTML (http://htmlpurifier.org/) Non si limita a filtrare l'HTML, fondamentalmente lo tokenizza e lo ricompila.È davvero una forza industriale.

Ha l'ulteriore vantaggio di consentire di garantire un output html/xhtml valido.

Inoltre, niente di tessile, è un ottimo strumento e lo uso sempre, ma lo eseguirei anche tramite il purificatore html.

Non credo che tu abbia capito cosa intendevo con i token.HTML Purifier non si limita a "filtrare", ma ricostruisce effettivamente l'HTML. http://htmlpurifier.org/comparison.html

Non ci credo.Html Encode converte tutti i caratteri funzionali (caratteri che potrebbero essere interpretati dal browser come codice) in riferimenti a entità che non possono essere analizzati dal browser e quindi non possono essere eseguiti.

&lt;script/&gt;

Non è possibile eseguire quanto sopra dal browser.

**A meno che non si tratti di un bug nel browser, ovviamente.*

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow