Dal punto di vista di uno sviluppatore, i primi due punti che hai non sono molto rilevanti. Stored e Reflected XSS hanno la stessa mitigazione: sfuggire correttamente alle cose che produci in base al loro contesto. I livelli di difesa saranno probabilmente visti solo come una scusa per una cattiva implementazione di questa mitigazione: "Il WAF me la prenderà".

Concentrati invece su queste pratiche di igiene del codice:

• Convalida, non scappare, in ingresso. La convalida dell'input dovrebbe essere solo per garantire che l'input abbia senso, non che sia "sicuro". A questo punto è impossibile sapere se è sicuro, poiché non conosci tutti i luoghi in cui verrà utilizzato.
• Presumi che tutti i dati non siano sicuri. Non dare mai per scontato che alcuni dati sono stati sottoposti a escape o che non includono tag o virgolette o entità o altro. Comprendi che l'input non sicuro può provenire da qualsiasi luogo: intestazioni HTTP, cookie, parametri URL, dati di importazione in blocco, ecc.
• Fuga al punto di utilizzo. Fuga dai dati per il contesto in quale viene utilizzato, quando viene utilizzato. Vuoi scappare solo una volta per migliorare le prestazioni? Assegna un nome alla variabile di destinazione in base a dove è sicuro da usare: jsstringsafeEmail , htmlattrsafeColor , htmltextsafeFullName , ecc.

Quali sono alcuni concetti che ritieni indispensabili per trasmetterli?

• Differenza tra Riflessi e memorizzati: non mi interessa davvero.
• Livelli di difesa - Sì. Molti sviluppatori non capiscono la "difesa in profondità". Supponi che ogni altra mitigazione abbia avuto esito negativo e che il tuo codice sia l ' ultimo elemento che si frappone tra l'aggressore e la risorsa vulnerabile. Che cosa puoi fare per mitigare l'attacco?
• Codifica sicura e contesto dei parametri di codifica - assolutamente
• e soprattutto, il potenziale impatto delle vulnerabilità. - assolutamente

Cos'altro? La cosa importante che manca dalla tua lista è: ci sono moltissimi strumenti e tecniche che possono essere tutti usati per mitigare queste potenziali vulnerabilità; la difesa in profondità suggerisce di usarne il maggior numero possibile.

• Sii sicuro per progettazione, sicuro per impostazione predefinita. Pensa alle vulnerabilità in tutte le fasi della progettazione e dell'implementazione. Assicurati di non essere protetto quando necessario e non di entrare quando necessario.
• Crea modelli di minaccia formali. Dove possono i dati ostili entrare in un sistema e dove possono uscire? Quali sottosistemi si fidano l'uno dell'altro e quali no? Se non sai dove sono i confini, è difficile rafforzarli contro gli attacchi.
• Le corde sono il nemico. I dati dovrebbero fluire in oggetti intelligenti che possono essere composti in modo intelligente, non stringhe che possono essere concatenate e divise.
• Se stai usando un linguaggio che ha un sistema di tipi, controlla se i dati sono contaminati o non contaminati il sistema di tipi. Fai in modo che il compilatore ti dica che stai assegnando dati contaminati a un contesto che si aspetta dati non contaminati.
• Se non hai un compilatore che trovi i tuoi bug, emula un sistema di tipi nella tua disciplina di denominazione. Se una variabile contiene dati contaminati, "contaminati" da qualche parte nel suo nome. Se assegni un valore contaminato a una variabile che non ha "contaminato" nel suo nome, hai appena rilevato un problema al momento della revisione del codice piuttosto che quando l'attaccante riesce.
• Utilizza strumenti di analisi statica progettati da professionisti della sicurezza per trovare questo tipo di problemi; prestare molta attenzione all'output, anche ai falsi positivi . Un falso positivo è un'indicazione che il codice non può essere visto come corretto da un analizzatore; ciò significa che probabilmente non può essere considerato corretto da un essere umano. Correggi il codice in modo che lo strumento non trovi più il falso positivo.
• Testa tutto come un attaccante, non un utente. Se è presente un codice che disinfetta l'input, incarica un membro della tua squadra di attaccarlo. Gli insetti disinfettanti sono una fonte comune di vulnerabilità difficili da individuare.
• Esegui test per errori di configurazione in produzione. I vuln XSS possono essere causati dalla disattivazione accidentale di alcune convalide o sanitizzazioni a scopo di debug o test e dimenticandosi di riattivarle, spingendo in produzione la configurazione sbagliata e così via.
• E così via.

Hai coperto la maggior parte delle nozioni di base. Per estendere un po 'i tuoi punti (alcuni di questi sembreranno ovvi alla maggior parte dei lettori qui, ma potrebbero non essere necessariamente ovvi a tutti gli sviluppatori):

• XSS può avvenire tramite GET e POST.
• XSS è anche un problema nei backend amministrativi.
• Esiste XSS basato su DOM.
• Esistono difese del browser, ma non dovrebbe essere invocato . Lo stesso vale per i WAF e le intestazioni dei server.
• La codifica dovrebbe avvenire durante la stampa, non quando si riceve l'input.
• Il contesto è davvero importante. La codifica HTML non è sufficiente in alcune situazioni.
• L'escape / codifica di JavaScript e CSS sono difficili. Si consiglia di utilizzare una libreria esistente.
• Tutti i parametri devono essere codificati. Non è un buon approccio codificare solo i parametri che sembrano non sicuri.
• È altamente raccomandato un filtro di input aggiuntivo (ad esempio, se hai bisogno di un numero intero, controlla che sia effettivamente un numero intero, idealmente localizzato in qualche classe di input), ma non dovrebbe mai essere l'unica linea di difesa.

Ma il punto più importante secondo me: la codifica HTML dovrebbe avvenire per impostazione predefinita , utilizzando un motore di modelli che codifica tutti i parametri per impostazione predefinita.

Se la codifica avviene ovunque, è troppo facile dimenticarla una sola volta. Ovviamente è ancora importante prendersi cura di tutte le situazioni in cui la codifica HTML non è sufficiente, ma la maggior parte delle vulnerabilità XSS verrà prevenuta dalla codifica predefinita.

Penso che le due lezioni più importanti da insegnare siano queste:

1. Se stai generando markup o qualsiasi altra rappresentazione testuale strutturata (ad esempio, JSON, SQL, stringhe di query URL) in un modo ad hoc concatenando le stringhe insieme, quindi interrompi immediatamente ciò che stai facendo e trova o crea una libreria centralizzata e sicura per il markup o generazione DOM.
2. Non fidarti delle strategie di prevenzione XSS che richiedono di eseguire una delle seguenti operazioni:
   • Indovina cosa tenterà l'attaccante o tenterà in altro modo di superare in astuzia l'attaccante. In particolare, i filtri lato input hanno una storia di essere stati superati in astuzia dagli aggressori e dovrebbero essere considerati con sospetto.
   • Identifica, più e più volte in contesti diversi, quali variabili sono input "non attendibili" che devi quindi trattare eccezionalmente. (Piuttosto, tutti gli input dovrebbero essere non attendibili per impostazione predefinita: dovresti disattivare la protezione XSS, non attivarla.)
ol >

---

Sul mio primo punto: quasi tutti i problemi di injection derivano dal lavorare al livello di astrazione sbagliato : i programmatori stanno concatenando stringhe in situazioni in cui dovrebbero usare operazioni di livello superiore che astratto lontano dal modo corretto di fare le cose. E questo significa che:

1. I programmatori finiscono per affrontare lo stesso identico, complicato problema più e più volte (la corretta escaping dei valori di stringa nel contesto in cui sono inseriti). Anche se riuscissero bene ogni volta (non probabile!), Le soluzioni non verrebbero mai riutilizzate.
2. Poiché la responsabilità di eseguire correttamente l'escape dei valori della stringa è diffusa in tutto il codice base invece di essere concentrata in un punto, controllare il codice per la sicurezza e risolvere i problemi diventa più difficile di alcuni ordini di grandezza.

---

Sul secondo punto: una buona lezione sui pericoli di fare affidamento sull'input- il filtraggio laterale sarebbe quello di sfogliare il XSS Filter Evasion Cheat Sheet di OWASP . Pensa a quella pagina come a documentare un tentativo fallito dopo l'altro e un altro di risolvere XSS attraverso il filtraggio sul lato input e l'intelligenza che gli aggressori sono stati in grado di utilizzare per aggirare il problema.

Spesso vedi anche molti consigli che parla di input "non attendibili" e di come elaborarli, il che è irto di pericoli perché:

• Capire quali input ci si può fidare è molto faticoso, in particolare quando devi farlo ancora e ancora;
• Potresti giudicare in modo errato quali input sono affidabili;
• Gli input di cui ci si può fidare oggi potrebbero non esserlo domani.

Il Cheat Sheet sulla prevenzione XSS di OWASP è un altro documento davvero eccellente che segue i miei due punti. Si concentra su come inserire in modo sicuro stringhe arbitrarie in documenti HTML, CSS e Javascript generati dinamicamente. Se risolvi il problema in un unico punto (in una libreria di terze parti o nella tua base di codice) e applichi quella soluzione in modo coerente in tutto, farai molto bene: avrai "tagliato la giugulare" delle vulnerabilità XSS.

Hai già elencato alcuni dei concetti più importanti: l'unica cosa che aggiungerei è l'ubiquità e la facilità di test per i vuln XSS. XSS è spesso la prima vulnerabilità che viene insegnata e dopo l'iniezione SQL forse la più famosa. È anche banale da scansionare e molti scanner di applicazioni come burp e w3af saranno in grado di rilevare automaticamente XSS.

Capire questo è importante perché delinea il motivo per cui xss esiste ancora: praticamente tutti i siti hanno un qualche tipo di protezione xss, ma sono ancora vulnerabili quando un tester o uno scanner intelligente è in grado di trovare l'input dell'utente che lo sviluppatore dimenticato. Per sviluppare in modo sicuro software xss-free, gli sviluppatori devono essere consapevoli degli aggressori che utilizzano vettori dispari per inviare payload, ad es. Intestazioni HTTP, menu a discesa, tutto ciò che può essere modificato in un proxy HTTP.

Il punto più importante da sottolineare, IMHO, è che dovresti sapere cosa contiene una variabile (o un campo di database). Devi sapere se è testo (e quale set di caratteri / codifica è, in quel caso), o è HTML (o un attributo HTML, che è ancora un altro tipo di dati), o SQL, ecc.

Quindi, è necessario applicare alle conversioni appropriate quando è necessario passare dall'una all'altra.

Il grosso problema è che in molti casi, la rappresentazione di una parte di testo (probabilmente il tipo più comune di dati che puoi manipolare) è lo stesso sia che si tratti di testo, HTML, SQL, ecc. (il testo "abc" è lo stesso dell'HTML abc o dell'SQL 'abc' ) e per questo motivo le persone tendono a concatenare i bit insieme senza alcuna conversione.

Ma ciò si interromperà non appena incontrerai caratteri che hanno un significato speciale in uno dei contesti. Questo non solo porta a problemi di sicurezza (sia XSS che SQL injection), ma anche a problemi di formattazione (abbiamo visto tutti siti che iniziano a mostrare entità HTML come < quando dovrebbero visualizzare < ), poiché le persone dimenticano la conversione o la fanno più volte.

È abbastanza raro che tu abbia effettivamente bisogno di consentire l'input dell'HTML effettivo. Nella maggior parte dei casi, vuoi del testo. Mantieni il testo così com'è, manipolalo così com'è. Ma una volta che desideri visualizzarlo (su una pagina HTML), convertilo in HTML (utilizzando librerie / framework standard e testati , non la tua ricerca e sostituzione improvvisata basata su regex).

Allo stesso modo, lo converti quando vuoi costruire una richiesta SQL (usando query parametrizzate, preferibilmente). Ma lo memorizzi ancora esattamente così com'è.

Molti framework aggiungeranno livelli di astrazione che "nascondono" tutto questo se li usi effettivamente. Ma sappiamo tutti che anche con gli strumenti migliori, ti ritroverai sempre con qualcuno che cerca di creare un po 'di HTML da solo, quindi deve sapere cosa deve essere fatto se lo fa.

Se vuoi / hai bisogno di manipolare l'HTML effettivo, allora inserisci una dimensione completamente diversa in termini di problemi XSS. Nota che può essere coperto in un'ora ...

XSS è serio

Esegui una dimostrazione di XSS per dimostrare che ha un impatto sul mondo reale, al di là di alert ('xss') .

XSS ci riguarda

Fornisci alcune statistiche, ad es 17 difetti XSS nei nostri prodotti sono stati identificati nei test di penetrazione durante lo scorso anno.

La soluzione sta sfuggendo

Mostra loro la differenza tra il codice che non lo fa ' t scappa, ed è vulnerabile, e il codice che scappa. Tentare di nuovo la dimostrazione e vedere come fallisce.

Buone pratiche di codifica

Mostra loro buoni modi per eseguire l'escaping con i linguaggi e i framework in uso nel tuo azienda. Idealmente un motore di modelli che esegue l'escape automatico. Se si dispone di un'unica lingua / framework in tutta l'azienda, è più facile. Altrimenti, mostra un esempio e dì loro di documentarsi sul particolare framework che stanno utilizzando.

Errori comuni

Contesto della pagina. Anche se disponi di un motore di modelli di escape, i dati non attendibili all'interno di un tag <script> possono causare XSS.

Quali dati non sono attendibili? ad esempio, se si recupera un feed RSS da un sito esterno, è ancora un rischio XSS, anche se non è un input diretto dell'utente.

DOM XSS: l'utilizzo di JavaScript eval e document.write può causare XSS.

Difesa in profondità

CSP è un'ottima difesa in profondità, ma può essere difficile da implementare.

Le opzioni dei cookie e la convalida della richiesta possono essere facilmente implementabili, ma sono solo difese parziali.

Chiedi aiuto

Quando si fa qualcosa di difficile, come consentire agli utenti di utilizzare tag HTML limitati nei commenti - chiedi assistenza a uno specialista della sicurezza.