Quali sono le librerie JavaScript lato client affidabili e stabili per la prevenzione dell'XSS e perché? Sarebbe molto utile se potessi fornire dettagli come:
Puoi aggiungere altri elementi all'elenco.
Innanzi tutto, l'XSS è un problema di output, che riguarda quasi sempre l'output del server ed è quindi corretto sul server. XSS consente a un utente malintenzionato di inserire JavaScript, che viene utilizzato per dirottare il browser ed eseguire qualsiasi azione come vittima.
L'unica soluzione di sicurezza XSS valida sul lato client ha una rigorosa politica di sicurezza del contenuto (CSP) che non consente iniezioni in linea. Il CSP è un insieme di regole definite dal server che vengono applicate dal browser e utilizzate per limitare l'esecuzione di JavaScript. Il CSP è uno strumento nuovo e molto potente per arrestare XSS.
Un altro approccio comune alla mitigazione XSS lato client consiste nell'utilizzare Modelli AngularJS . Un linguaggio modello sicuro come AngularJS mitigherà l'XSS neutralizzando il codice eseguibile che doveva essere visualizzato come testo. Questo è un ottimo approccio allo sviluppo di applicazioni sicure. Tuttavia un'applicazione che utilizza AngularJS non può proteggere da chiamate API vulnerabili a XSS, solo il CSP può farlo.
AngularJS + CSP renderà molto difficile l'utilizzo di un'applicazione con XSS, ma nulla è al 100%. Esiste ancora la possibilità di XSS basato su DOM e Strumenti cross-site in Flash , entrambi molto simili tra loro. Non vi è alcuna mitigazione generale qui, nemmeno un WAF (Web Application Firewall) può fermare questi attacchi: sono perfetti e diffusa .
Come cita la risposta di @Rook, l'unico modo che JS può proteggere contro XSS è quando si utilizza un framework (come Angular) che recupera tutti contenuto di pagina dinamico tramite JS (di solito usando XmlHttpRequest ) e poi lo inserisce in modo sicuro nella pagina. Come sottolinea @GeorgeMauer, tu (o il tuo framework) puoi tranquillamente fare questo passo iniettare-nella-pagina usando la proprietà textContent / innerText di un elemento DOM, ma poi perdi la capacità di specificare qualsiasi tipo di formattazione dinamica a tutti A volte va bene, a volte no.
Lo script sul lato client non può mai proteggere contro le iniezioni di XSS che vanno al server. Come suggerisce il nome, XSS viene spesso iniettato attraverso i siti, quindi il codice lato client non può catturare l'iniezione perché non sta nemmeno accadendo sul tuo sito (e quindi il tuo codice lato client non è in esecuzione). XSS memorizzato viene spesso iniettato all'interno del sito di destinazione, ma ancora una volta, la convalida sul lato client non sarà di aiuto; l'attaccante può (e lo farà) disabilitare la convalida (controllano il client, controllano il codice lato client che viene eseguito su di esso) o crea semplicemente la richiesta HTTP dannosa (POST o altro) usando uno strumento come curl o Burp Suite .
Allo stesso modo, il codice lato client non può proteggere contro contenuti HTML / JS dannosi restituiti dal server Web in risposta a una richiesta di pagina. Nel momento in cui vengono eseguiti i controlli di disinfezione (o qualsiasi altra cosa), lo stesso vale per il codice dannoso; è troppo tardi! Devi fare tutte le tue validazioni / escaping / quant'altro prima che il codice colpisca il motore di rendering / JS. Ci sono solo due modi per farlo: eseguilo sul lato client su stringhe JS che poi aggiungi al contenuto della pagina (questo è il modo in cui Angular e gli amici lavorano, ma non sono infallibili) o fallo sul server .
Allo stesso modo, non c'è batteria di test che valga il tempo necessario per compilarli. Puoi lanciare tutti gli scanner automatici che desideri sul tuo codice, ma se hai solo costruito le protezioni al livello necessario per battere quegli scanner e l'aggressore intelligente probabilmente li sorpasserà. Lo faccio tutto il tempo. Gli scanner hanno solo due uscite: vulnerabili e forse vulnerabili . Non possono dirti che sei al sicuro.
Non andare per una copertura minima. Non cercare di essere carino e fare tutto sul lato client; anche se stai usando qualcosa come Angular, funziona sul presupposto che sia vulnerabile e fai la tua validazione dell'input e la codifica dell'output sul server! Invece di cercare di essere al sicuro da minacce conosciute e speri di ottenere protezione aggiornata contro quelle future, fare in modo che il server restituisca solo il codice che è sicuro che sia sicuro. Con tutti i mezzi eseguire uno scanner, ma anche assumere qualcuno che sa quello che stanno facendo per pentestarlo per davvero, se sei preoccupato per la sicurezza.
Che ne dici di mettere sempre il testo nel DOM impostando textContent su un DOM elemento ?
Pro:
innerText ma abbastanza semplice da shim). Contro:
<em> . Come nota a margine, menzionerò che molte persone pensano che questo significhi che puoi creare un elemento, impostare textContent , e quindi prendere innerHTML per disinfettare il testo. Questo non è il caso .
Vi aiuterò affermando che non dovreste usare una libreria di gestione delle sessioni e un'architettura basate sul passaggio di dati sensibili (come un ID di sessione) al client e l'archiviazione nei cookie localStorage o non httpOnly di HTML5, questo è la citazione da OWASP :
Data stored in this object will persist after the window is closed, it is a bad idea to store sensitive data or session identifiers on this object as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.
L'uso dei cookie con il flag httpOnly impedirà (nei browser che lo supportano) il rischio che qualsiasi script estragga tali dati dal localStorage. Ci sono ancora altri rischi, naturalmente, ma questo aiuterà anche.
Leggi altre domande sui tag vulnerability xss