Sto lavorando per un sito di e-commerce scritto in C # .net (nessun CMS utilizzato, un bel po 'di codice) in cui la sicurezza non è stata una priorità per un lungo periodo. La mia missione adesso è trovare e correggere qualsiasi violazione XSS. Vi sono molti dati non filtrati scritti direttamente nel codice HTML visualizzato.
Qual è la mia migliore strategia per curare il codice senza dover leggere ogni singola pagina?
Propongo il seguente programma in quattro fasi, in cui per prima cosa scegli la frutta bassa che appende per darti un minimo di protezione mentre lavori sui problemi più grandi.
L'impostazione dell'intestazione della risposta HTTP che segue attiva i browser integrati nella protezione XSS:
X-XSS-Protection: 1; mode=block
Questo non è assolutamente impermeabile, e aiuta solo contro l'XSS riflesso, ma è qualcosa. Alcune vecchie versioni di IE (sorpresa, sorpresa) hanno un filtro bacato che in realtà potrebbe peggiorare le cose, quindi potresti voler filtrare alcuni programmi utente.
Se non usi JavaScript in linea nella tua app, un CSP può aiutare Un sacco. L'impostazione di script-src 'self' (a) limita i tag di script solo per includere script dal proprio dominio e (b) per disabilitare gli script inline. Quindi, anche se un utente malintenzionato potrebbe iniettare <img onerror="alert('XSS')"> , il browser non eseguirà lo script. Dovrai personalizzare il valore che utilizzi per l'intestazione a tuo piacimento, ma la risorsa MDN collegata dovrebbe aiutarti.
Ma ancora, questo non è impermeabile. Non fa nulla per aiutare gli utenti con un browser che non implementa CSP (vedi qui ). E se la tua fonte è piena di script inline dovrai scegliere tra ripulire o astenersi dall'uso di CSP.
John Wu ha un buon suggerimento nei commenti:
Also, since this is .NET, a very quick and easy change can turn on ASP.NET Request Validation which can catch a variety of XSS attacks (but not 100% of them).
Se lavori in un'altra lingua, potresti invece considerare l'utilizzo di un firewall per applicazioni web (come suggerito da xehpuk ). Quanto è semplice configurare un WAF per te dipende dall'applicazione che stai proteggendo. Se stai facendo cose che rendono il filtraggio intrinsecamente difficile (ad esempio, passa HTML nei parametri GET o POST), potrebbe non valere la pena di configurarne uno.
Ma ancora una volta, mentre un WAF potrebbe aiutare, non è ancora impermeabile.
Utilizza uno scanner XSS automatizzato per trovare le vulnerabilità esistenti e risolverle. Come complemento puoi eseguire i tuoi test manuali. Questo ti aiuterà a focalizzare il tuo tempo prezioso sulla risoluzione delle vulnerabilità facili da trovare, dandoti il massimo del botto nella fase iniziale.
Ma per la terza volta, questo non è impermeabile. Non importa quanto tu scruti e test, ti mancherà qualcosa. Quindi, sfortunatamente, c'è un punto 4 in questa lista ...
Sì, dovrai "leggere ogni singola pagina". Passare attraverso la fonte e riscrivere tutto il codice che genera i dati utilizzando una sorta di framework o libreria di modelli che gestisce i problemi XSS in modo sano. (Probabilmente dovresti scegliere un framework e iniziare a usarlo per le correzioni che fai già al punto # 3.)
Ci vorrà molto tempo, e sarà un dolore nella a **, ma deve essere fatto. Guardala dal lato positivo - hai l'opportunità di fare qualche altro refactoring mentre ci sei. Alla fine non avrai risolto il tuo problema di sicurezza, avresti anche una base di codice migliore.
In breve, non esiste una soluzione facile. Ho un suggerimento per una soluzione "facile" in fondo, ma tieni presente che contiene molti avvertimenti, che discuterò qui. Per prima cosa, iniziamo dal grande quadro e procediamo verso il basso.
Nella mia esperienza (avendo lavorato con molti sistemi legacy) "la sicurezza non è stata una priorità per un lungo periodo" significa che probabilmente nel tuo sistema ci sono molti problemi di sicurezza nascosti. XSS è solo un problema, ne sono sicuro. Quindi, a meno che tu non sappia che qualcuno è già in cima a questi, mi preoccuperei di:
I numeri non intendono implicare priorità: sono tutte priorità principali.
Il punto di partenza
La cosa più importante è risolvere questo "istituzionalmente". Questo sarà il più difficile da fare, ma è anche il più critico. Se passi qualche settimana a sistemare tutte le tue vulnerabilità XSS, ma la sicurezza continua a essere una priorità di livello inferiore, il problema tornerà la prossima volta che uno sviluppatore invierà dati non filtrati al browser.
Le migliori protezioni contro le vulnerabilità XSS sono gli sviluppatori che sanno prendere sul serio la sicurezza e utilizzare un motore di template che gestisca in modo appropriato l'escape di XSS. La chiave da ricordare è che con XSS devi filtrare in output, non in input. È facile vederlo come un problema a senso unico "Pulisci i dati utente quando entrano nell'input, e poi stai bene". Ma questo non protegge da tutti i vettori di attacco, in particolare XSS aggiunto tramite SQLi. In generale, però, se la protezione XSS è qualcosa che i tuoi sviluppatori devono fare per ricordarti di fare ogni volta, finirà per essere dimenticata. Ecco perché la soluzione migliore è quella di avere quella protezione XSS integrata nel tuo sistema. È qui che entra in gioco un motore di template. Qualsiasi sistema di template competente applica automaticamente il filtro XSS per impostazione predefinita e, in particolare, deve essere informato se è necessario il filtro not per XSS.
Sono certo che il refactoring del sistema per includere un motore di template specifico per occuparsi delle vulnerabilità XSS probabilmente non accadrà, ma è anche importante capire che se non si fa qualcosa per risolvere il problema istituzionale questo ha permesso che ciò accadesse, in primo luogo, il problema sta per tornare, e le settimane che ti occorreranno per risolvere questo problema saranno sprecate.
Primi passi pratici
@Anders ha alcuni ottimi punti di partenza nella sua risposta. Un CSP e l'intestazione XSS funzionano entrambi allo stesso modo: dicendo al browser di abilitare il lato client di protezione XSS. Tieni presente che, come menzionato da @Anders, questi sono dipendenti dal browser e, soprattutto per i browser meno recenti, potrebbero non essere supportati affatto. In particolare, il supporto di IE per CSP è minimo, anche fino a IE11 ( link )
Il risultato è che mentre questi passaggi sono buoni punti di partenza, non puoi sicuramente fare affidamento su di essi come la tua sicurezza principale: devi ancora risolvere il problema sulla tua estremità. Ottenere un buon strumento di scansione automatico è sicuramente il modo migliore per iniziare. Ti darà alcuni elementi di azione immediati.
Una soluzione parziale
Un'altra opzione che potresti avere consiste nel mettere il filtro XSS su tutta la linea della tua applicazione. Normalmente non lo consiglio, ma penso che la soluzione migliore per voi sia una risposta a più livelli. L'idea è di aggiungere del codice al processo di bootstrap delle applicazioni che controlla tutti i dati in arrivo dal client (dati url, dati POST, cookie, intestazioni REQUEST, ecc ...). Quindi esegui alcuni filtri per rilevare i payload XSS comuni e, se trovato, rifiuta la richiesta tutti insieme.
Il problema con il filtro della lista nera è che può essere molto inaffidabile. Se hai letto il foglio di evasioni del filtro OWASP XSS ti farai un'idea di quanto sia difficile essere affidabile filtrare le vulnerabilità XSS. Tuttavia, è un modo rapido per ottenere protezione su ogni richiesta, quindi potrebbe essere utile nel tuo caso. Un aspetto importante da tenere presente è che in genere questo impedirà agli editor WYSIWYG di funzionare. Questo potrebbe o non potrebbe essere un problema per te.
Leggi altre domande sui tag .net web-application xss whitebox