XSS è una forma di iniezione di codice, ovvero l'autore dell'attacco riesce a iniettare il proprio codice dannoso (solitamente JavaScript) in codice attendibile (HTML, CSS, JavaScript) fornito dal sito. È simile a SQLi in quanto è causato da un codice costruito dinamicamente, cioè istruzioni SQL, pagine HTML ecc.

Ma mentre esistono tecniche consolidate per risolvere SQLi (ad esempio utilizzare il binding di parametri) è ancora più difficile con XSS. Per difendersi da XSS, ogni input controllato dall'utente deve essere debitamente scappato, il che è molto più difficile di quanto possa sembrare:

• Le regole di escape dipendono dal contesto, ad esempio HTML, HTML, XHTML, URL, script, i contesti CSS hanno tutte regole di escape diverse.
• Questi contesti possono essere annidati, ad esempio qualcosa come <a href=javascript:XXX > è un contesto JavaScript all'interno di un contesto URL all'interno di un attributo HTML.
• Inoltre, hai regole di codifica per i caratteri (UTF-8, UTF-7, latin1, ...) che possono essere ancora specifici del contesto.
• Il contesto e la codifica devono essere conosciuti quando si costruisce l'output: mentre la maggior parte dei motori di template supportano l'escape HTML corretto spesso non sono a conoscenza del contesto circostante e quindi non possono applicare le regole di escape specifiche del contesto.
• In aggiunta, i browser possono comportarsi in modo leggermente diverso rispetto all'escaping o alla codifica.
• A parte questo, troverai spesso nel codice sviluppato una separazione non corretta della logica e della presentazione che i frammenti HTML vengono archiviati nel database e non è sempre chiaro allo sviluppatore se un valore specifico è già HTML pulito o necessario essere sfuggito.

E anche se ci sono alcuni semplici modi per proteggere XSS dalla progettazione (in particolare Content-Security-Policy) questi funzionano solo con i browser più recenti, devono essere esplicitamente abilitati dallo sviluppatore e sono spesso efficaci solo dopo grandi (e costosi) modifiche al codice (come la rimozione di script inline).

Tuttavia, ci sono buone possibilità di farlo correttamente se si hanno sviluppatori con le giuste conoscenze e si è in grado di ricominciare da zero usando moderni toolkit che già si occupano di XSS. Sfortunatamente in molti casi esiste un codice legacy sul quale è necessario continuare a lavorare. E lo sviluppo è di solito fatto da sviluppatori che non sono a conoscenza di XSS o non conoscono tutte le insidie.

E finché lo sviluppo del web viene fatto in ambienti molto sensibili al costo e al tempo, le probabilità sono basse che questo cambierà. L'obiettivo in questo ambiente è di far funzionare il codice in breve tempo e con costi contenuti. Le aziende di solito competono per caratteristiche e time to market e non per chi è il prodotto più sicuro. E la protezione XSS attualmente significa solo costi aggiuntivi senza alcun vantaggio evidente per molti gestori.

Sembra facile, ma è difficile

Innanzitutto, la superficie di attacco è enorme. Devi occuparti di XSS se vuoi visualizzare l'input dell'utente in HTML ovunque. Questo è qualcosa che quasi tutti i siti fanno, a meno che non siano costruiti puramente in HTML statico.

Combina questo con il fatto che mentre XSS potrebbe sembrare facile da gestire, non lo è. Il foglio cheat di prevenzione OWASP XSS è lungo 4 000 parole. Hai bisogno di un foglio abbastanza grande per contenere tutto il testo.

La complessità insorge perché XSS funziona in modo diverso in contesti diversi. È necessario fare una cosa se si inseriscono dati non attendibili in JavaScript, una cosa se si inserisce nei valori degli attributi, un'altra cosa se si inserisce tra i tag, ecc. OWASP elenca sei diversi contesti che hanno bisogno di regole diverse, oltre a un numero di contesti dove non dovresti mai inserire dati.

Nel frattempo gli sviluppatori sono sempre alla ricerca di panachea e proiettili d'argento. Desiderano deletare tutto il duro lavoro a una singola funzione sanitize() che possono sempre richiamare dati non fidati, chiamarli un giorno e andare avanti con la programmazione reale. Ma mentre molte di queste funzioni sono state codificate, nessuna di esse funziona.

Lasciami ripetere: XSS potrebbe sembrare facile da gestire, ma non lo è. Il pericolo principale risiede nella prima parte di questa frase, non nella seconda. La semplicità percepita incoraggia gli sviluppatori a creare le proprie soluzioni prodotte in casa - le proprie funzioni sanitize() personalizzate, piene di generalizzazioni, liste nere incomplete e ipotesi errate. Hai filtrato javascript: in URL, ma hai pensato a vbscript: ? O javaSCripT : ? Hai citato le virgolette, ma ti sei ricordato di allegare il valore dell'attributo tra virgolette? E per quanto riguarda le codifiche dei caratteri?

La situazione è abbastanza simile a SQLi. Tutti hanno continuato a cercare la sola funzione di risanamento per domarli tutti, sia denominata addslashes , mysql_escape_string o mysql_real_escape_string . È la sicurezza del culto del carico, in cui le persone pensano che sia sufficiente chiamare ritualmente la funzione giusta per placare gli dei, invece di abbracciare effettivamente la complessità del problema.

Quindi il pericolo non è che gli sviluppatori siano beatamente inconsapevoli di XSS. È che pensano di avere la situazione sotto controllo, perché hey, ho programmato una funzione per questo.

Ma perché è difficile?

Il web soffre del problema che struttura (HTML), presentazione (CSS) e dinamica (JavaScript) sono tutti mescolati in lunghe stringhe di testo che abbiamo inserito in .html file. Ciò significa che ci sono molti limiti che puoi attraversare per spostarti da un contesto all'altro.

Di nuovo, questo è lo stesso di SQLi. Ci si mescolano le istruzioni e i valori dei parametri in una stringa. Per fermare SQLi, abbiamo capito che dobbiamo separare completamente i due e non mischiarli mai - ad esempio, utilizzare le query parametrizzate.

La soluzione per XSS è simile:

1. Separa gli script dall'HTML.
2. Disattiva gli script incorporati nel codice HTML.

Abbiamo creato un modo semplice per eseguire la seconda parte: Content Security Policy . Tutto quello che devi fare è impostare un'intestazione HTTP. Ma la prima parte è difficile. Per una vecchia web app, una riscrittura completa potrebbe essere più semplice che separare chirurgicamente lo scripting dall'HTML. Quindi è più facile fare affidamento solo su quella magia sanitize() e sperare per il meglio.

Ma la buona notizia è che le nuove app spesso vengono sviluppate in base a principi più rigorosi, l'uso del CSP è possibile e quasi tutti i browser lo supportano ora. Non sto dicendo che avremo la percentuale di siti vulnerabili fino allo 0%, ma spero che cadrà molto dal 60% nei prossimi anni.

TL; DR: Questo si è trasformato in un rant piuttosto lungo. Non sono sicuro che ci siano molte informazioni utili qui - basta leggere Steffen Ullrichs che risponde magnificamente se vuoi un'analisi chiara.

Il mio set di opinioni su sicurezza e XSS:

1. Regola di programmazione: non puoi sapere tutto. Prima o poi commetterai un errore.
2. Regola del programmatore: un programmatore lavora 12 ore al giorno: 3 sta discutendo con altri programmatori di cose casuali, 3 sta pensando ad altro, 3 sta discutendo su cosa dovrebbe codificare, 3 sta programmando .... i progetti sono fatti per 12 ore al giorno di programmazione quasi continua.
3. XSS è semplice. E ci sono molti input in attesa di XSS.
4. La sicurezza arriva ancora l'ultima volta e la maggior parte delle volte è vista come carente.

Come menzionato nella risposta a un tuo post simile ( SQL injection ha 17 anni. Perché è ancora in circolazione? ):

There is no general fix for SQLi because there is no fix for human stupidity

Gli sviluppatori a volte diventano pigri o negligenti e questo li induce a non controllare l'applicazione che stanno sviluppando.

Un altro motivo popolare è che gli sviluppatori non sono a conoscenza del fatto che esiste un problema di sicurezza. Non hanno mai seguito alcun addestramento sulla sicurezza e quindi non sanno quale sia una potenziale minaccia alla sicurezza e cosa no. E per le aziende che non capiscono che un test di penetrazione è importante, questa mancanza di conoscenza della sicurezza è una potenziale minaccia di per sé.

Semplici problemi di sicurezza come SQLI e XSS verranno risolti solo quando un'azienda deciderà di dedicare tempo alla revisione e al test del codice. Fino ad allora, il 65% di tutti i siti Web a livello globale soffre della vulnerabilità XSS.

Il problema root

Il web non è stato semplicemente progettato per consentire una multi-paternità sicura o una ricca interazione. Nessuno ha parlato della separazione dei contenuti dalla presentazione fino alla fine degli anni '90. A quel punto, come la tastiera QWERTY, eravamo praticamente bloccati senza una buona ragione con un sistema esistente. Nessuno voleva "rompere il web", quindi gli errori venivano copiati e portati sui browser oltre il "primo vettore".

Il fattore aggravante

Prima del ~ 2005, praticamente tutto ciò che vedevi su un determinato sito web è stato creato o approvato dalle persone che controllano il sito. Con il progredire del movimento "Web 2.0" e le persone hanno richiesto l'interazione (almeno aggiungere commenti, dai!), La pressione per aggiungere queste funzionalità ai siti esistenti è stata grande. La gente del Web ha fatto quello che poteva per soddisfare le richieste del capo di svolgere un compito di cui non sapevano nulla: l'interazione sicura. E per un po ', probabilmente troppo a lungo, se la sono cavata. Quante persone acquistano gli allarmi per il ladro prima in cui sono stati addirittura suddivisi?

Tempi moderni

L'uso di un CSP ridurrà di molto il potenziale di danno del lancio di un'altra palla. Ciò non significa che dovresti rinunciare alla validazione e ai servizi igienico-sanitari con qualsiasi mezzo, a causa delle copie di Save As .., memorizzate nella cache senza intestazioni, ecc., Ma significa che puoi essere PIÙ SICURO con un paio d'ore di sforzo. Sì, l'intestazione è prolissa e in un formato confuso all'inizio, ma investe l'ora o due che serve per farla franca, e le poche altre ci vorranno per testare il tuo sito. CSP è davvero facile da testare poiché puoi eseguire un'esecuzione silenziosa di sola ammonizione (cercalo).

Se arrotoli un CSP e prendi misure tradizionali, quei vecchi browser moriranno quando il disco rigido smetterà di girare e vivremo tutti al sicuro e felici per sempre ...

Altri hanno toccato i classici problemi che circondano i sistemi progettati dagli umani per gli altri umani: la realtà è la pigrizia e, a volte, la stupidità accoppiata a "Perché dovrebbe succedere a me?", arroganza.

Oh, quante ore della mia vita sono state spese per sistemare i sistemi e, cosa più importante, combattere con il management per ottenere il tempo / le risorse assegnate ai sistemi di patch in modo che possano essere "a prova di proiettile".

E sono fortunato a questo riguardo: mentre sono frustrato a combattere con il management di un'organizzazione per ottenere un sistema rattoppato, molti posti assumono sviluppatori per sviluppare un sistema ma poi non considerano la manutenzione base (e noiosa) da Qualcosa per cui vale la pena investire. Perché pagare una tecnologia un fermo mensile per mantenere un sistema quando è spesso più economico lasciare che il sistema regga fino a quando non crolla e poi inseguire una soluzione nel mezzo di una breccia?

Un grammo di prevenzione è meglio di un chilo di cura spesso prende un posto indietro per la gente che è pestifera, sterlina-sciocca.

Detto questo, la cosa migliore che chiunque possa amministrare un sistema può fare è disporre di un solido piano di ripristino di emergenza (o non di emergenza). Tenere sotto controllo la versione del codice, disporre la configurazione della distribuzione del server automatizzata in uno script di provisioning e disporre di backup dei database. In questo modo se / quando un sistema va giù, la pulizia è veloce invece di essere un noioso disastro.

Il rilevamento accurato di vulnerabilità di sicurezza pericolose come SQLI e XSS durante la fase di implementazione del codice di SDLC è ancora limitato al tipo di linguaggio di programmazione.

• L'analisi statica per tali vulnerabilità è più ampiamente eseguita in PHP.
• Alcuni metodi dinamici impiegano tecniche fuzzy durante la fase di test o di implementazione.

Sfortunatamente, entrambi i metodi sono ancora piuttosto limitati nel loro tasso di precisione. Inoltre, le vulnerabilità XSS e SQLI sono destinate alle applicazioni per computer e possono apparire in così tante forme mascherate che sono sconosciute agli sviluppatori di software. In quanto tale, non penso che sia una questione di stupidità. Posso assicurare che alcune aziende hanno già formato i loro sviluppatori per la programmazione sicura, ma non possono bloccare totalmente queste vulnerabilità. Sono d'accordo che c'è molto di più che deve essere fatto per prevenire tali attacchi critici.