Blacklisting vs whitelisting caratteri per prevenire XSS?

Non è solo un blocco di caratteri manciati che è necessario inserire nella lista nera. In sicurezza andiamo da questo dogma:

"There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don't know. But there are also unknown unknowns. There are things we do not know we don't know."

La lista nera potrebbe aiutarti a prevenire i primi due casi, una lista bianca aiuta a coprire tutti e tre questi aspetti:)

Mentre è facile identificare e convalidare una serie di caratteri innocui, è difficile identificare tutti i cattivi conosciuti. La maggior parte dei software anti-virus utilizzano l'approccio blacklist (firme), tuttavia non riescono a catturare uno 0-day perché era qualcosa che non conoscevano come noto e quindi non aveva una firma per questo.

Also, why is whitelist approach better than blacklist approach as mentioned by OWASP. Why not just block a handfull of characters used in XSS like < , > , etc

Le blacklist sono statiche nel senso, impediscono che avvenga il 'noto male'. Il problema con questo è, ci sono nuovi vettori di attacco trovati ogni giorno e avresti bisogno di aggiornare costantemente la tua lista nera per essere al sicuro. La whitelist d'altra parte è più solida perché, è possibile creare un filtro esattamente su ciò che si desidera. Questo risponde alla tua domanda sul perché le whitelist sono suggerite da OWASP.

Penso che potresti aver rifiutato ESAPI troppo velocemente. Per difendersi da XSS, ti consiglio di eseguire l'escaping dell'output: qualsiasi posizione in cui inserisci i dati dinamicamente in un documento HTML, sfugge ai dati (in un modo adatto a tale contesto di analisi). ESAPI fornisce librerie per l'escape ed è molto utile. Questo non implica "cambiare il tuo input".

Per ulteriori informazioni, leggi il foglio Chess di prevenzione XSS (Cross Site Scripting) di OWASP e < a href="https://security.stackexchange.com/q/1368/971"> Qualcuno può spiegare XSS a un idiota? e Filtrare l'input dell'utente prima del database o sul display? e Canonicalization & Codifica dell'output .

do input filtering

No, no, no.

In ogni caso, inserisci validation - accetta o rifiuta l'input in base alle regole. Non provare a modificare i dati di input. Se l'interfaccia tra il server web e il linguaggio dell'applicazione consente contenuti che compromettono il linguaggio dell'applicazione, allora c'è qualcosa di molto, molto sbagliato. Certamente non puoi gestire questo tipo di scenario all'interno del codice dell'applicazione.

Le vulnerabilità nelle applicazioni si verificano in genere nel momento in cui i dati lasciano il linguaggio dell'applicazione e, nel caso dell'XSS, questo è il punto in cui si presentano. Quindi questo è il punto in cui dovresti applicare qualsiasi trasformazione ai dati. Una trasformazione deve essere appropriata a dove stanno andando i dati - il modo in cui sfuggite ai dati che scrivete su un database è molto diverso dai dati da scrivere in html.

Idealmente, i seguenti passaggi dovrebbero essere eseguiti sull'input:

1. Filtro (facoltativo). Rimuovi gli spazi bianchi attorno ai valori. Ad esempio, per un numero di telefono potresti voler rimuovere spazi, trattini e punti, perché alcune persone cercano di inserire cose come 046 339 1312 .

2. Convalida .

   a. Ciò impedisce errori utente non rilevati dal filtro.

   b. I controlli di convalida dovrebbero funzionare come whitelist. Con la corretta escaping (vedi punto 3 sotto) questo non dovrebbe essere necessario per la sicurezza, ma potrebbe bloccare un attacco non ancora scoperto in futuro. Fai attenzione però, è spesso più difficile di quanto sembri.

   Se si dovrebbe andare per qualcosa di base (come solo il controllo per un @ segno durante la convalida degli indirizzi e-mail) o un'espressione regolare esatta e rigorosa, dipende dal fatto che tu conosca tutti i valori possibili e se sia davvero necessario farlo correttamente. Per un sito con dati della carta di credito nel suo database, potresti voler dedicare ancora più tempo alla ricerca di possibili input.

   c. Si consiglia inoltre di convalidarlo come, il dominio in questo indirizzo e-mail esiste anche? Oppure questo numero è veramente valido ? Potresti anche provare se un server di posta accetta l'utente (Gmail commetterà un errore quando un utente non esiste, anche prima che tu invii realmente qualcosa), ma il server potrebbe essere inattivo. SMTP gestirà questo per te e ritarderà la consegna, ma il tuo verificatore di indirizzi e-mail dal vivo dirà all'utente che il suo indirizzo non esiste mentre lo fa totalmente.

3. Escape . Questo dovrebbe essere fatto sia per input che per output . Immettere quando lo si salva in un database, emesso quando lo si sta visualizzando. Sì, anche i dati di escape provengono direttamente dal tuo database. Un apostrofo può essere totalmente innocuo in HTML, mentre l'utilizzo in Javascript può fornire una grande opportunità XSS. Oppure un < non sarà scappato da mysql_real_escape_string , ma se lo metti in uscita su una pagina HTML hai un altro XSS.

Non riesco a pensare a un caso d'uso in cui i passaggi precedenti renderebbero una lista nera pratica o necessaria, quindi consiglio di non utilizzarla. Ci può sempre essere una ragione però. L'evasione dovrebbe occuparsi del resto indipendentemente, ma è bene avere un'altra difesa.

Quando è abbastanza importante, puoi anche scrivere un test unitario per testare tutti gli input possibili e gli exploit comuni: ../, ', ", \, numeri, stringhe o anche il set ASCII completo.