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 .
- Escaping? Ottima idea, dovresti fare in modo che il tuo server lo faccia!
- Liste nere? Idea terribile, perdita di tempo e un falso senso di sicurezza.
- Whitelisting? Una buona tecnica di validazione dell'input; dovresti fare in modo che il tuo server lo faccia.
- Se fai la tua parte sul lato di prevenzione XSS, allora il browser non sa o cura. Tutti i browser comprendono gli escape di URL, HTML e JavaScript.
- Non ci sono "standard" sulla sicurezza XSS, non più di "standard" sulla sicurezza della memoria del codice nativo.
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.