Scenario app JavaScript limitato: vettori di attacco e mitigazione

• What attack vectors are there in this kind of scenario?

L'XSS basato su DOM è il più grande.

Normalmente ciò può consentire una serie di operazioni di key-logging, estrazione dei dati sulla pagina, XSRF, reindirizzamento a un sito di phishing, drive-by-downloads.

Ma finché viene visualizzato nuovamente all'utente che lo ha inserito e non persiste, non è un problema.

• What would you do to mitigate any attack vectors?

Utilizza document.createTextNode(plainText) per inserire il testo nel DOM anziché node.innerHTML = plainText .

Assicurati di non precompilare la casella di testo con i dati dall'URL in modo che sia realmente vero che i dati sono stati immessi dall'utente.

Non consentire l'inquadratura del tuo sito per impedire che la pagina di un utente malintenzionato avvolga la tua pagina e socializzi l'utente nella copia e incolla del contenuto nella casella di testo.

Le due maggiori minacce sono Clickjacking e l'accesso allo spazio di archiviazione offline. È possibile che l'archiviazione offline sia accessibile con XSS basato su DOM o se la macchina che lo esegue è stata compromessa. Anche se la tua applicazione non usa GET / POST / Fragment come input, una delle tue librerie potrebbe.

Evita XSS lato client (noto anche come XSS basato su DOM). Leggi OWASP per risorse su questo argomento. Vedi anche il consiglio di Adam Barth su questo argomento , che è eccellente.

Una versione breve: per l'amor del cielo, non utilizzare setInnerHTML , document.write() o eval() sul testo che l'utente inserisce nella textarea. Utilizza setInnerText (o document.createTextNode ecc.) Invece di setInnerHTML .

Supponendo che nessun dato sia letto da nessuna parte (come i parametri GET), l'unico attacco possibile è che il documento html venga manomesso quando viene caricato. Se è caricato localmente, la versione sul disco può essere manomessa; se è caricato da un server senza https, il documento può essere cambiato durante il trasferimento o modificato sul server.

Oltre a questo, se non vi è alcun input o output (oltre a ciò che è digitato e visibile sullo schermo, voglio dire cose come il salvataggio su disco), non vedo quali attacchi potresti eseguire che non puoi ogni altro campo di input sul sistema.

Modifica: Oh, mancava questa parte: Any input will need to be redisplayed to the user who has entered it. La frase precedente a quella suggerita sarebbe stata cancellata. Questo potrebbe effettivamente essere un vettore di attacco, ad esempio quando la cache viene manomessa. Non penso che ci siano grossi rischi in questo però.