Inietti markup personalizzato tramite vanilla JS senza aumentare il rischio di XSS lato client? [duplicare]

Question

Inietti markup personalizzato tramite vanilla JS senza aumentare il rischio di XSS lato client? [duplicare]

#1 da (1 voti)

1

Il mondo del software aziendale business-to-business ha sempre richiesto un elevato livello di markup personalizzato per client associato al branding e alla personalizzazione. In una SPA che in genere significa iniettare markup nello script.

Alcuni post tout framework come angular.js per un rendering più sicuro di questo tipo. Tuttavia, in molte situazioni vi è una crescente pressione per spostarsi dai quadri al testo vanilla. Vi sono vantaggi in termini di prestazioni, integrazione, manutenzione e così via. Ciò è alimentato dall'aumento delle dimensioni e dalla complessità delle strutture esistenti, dalle nuove versioni principali che partono radicalmente da quelle precedenti e dalla costante diminuzione del mercato del framework JavaScript.

Quali sono le corrette misure di sicurezza lato client per iniettare markup usando vanilla JS?

Non contrassegnarlo come un duplicato di domande XSS più generali lato client senza il requisito vanilla js o il requisito per client personalizzato (questo potrebbe essere definito come non attendibile, ma lo sconosciuto potrebbe essere più accurato dato che emana dal client).

javascript client-side xss single-page-app

posta cage rattler 24.08.2016 - 17:26

fonte

1 risposta

Leggi altre domande sui tag javascript client-side xss single-page-app

Previeni perdite DNS nel terminale Il server GPG nasconde i risultati della ricerca?

score 1 · Accepted Answer

Non sono sicuro di aver letto bene, ma penso che tu voglia inserire HTML non sicuro nel DOM usando JavaScript? Se è così, questi sono i miei consigli:

Prima di tutto è necessario un purificatore o disinfettante HTML o qualsiasi altra cosa si voglia chiamare, che rimuove qualsiasi CSS o script inline. Un esempio è Google Caja , ma sono sicuro che ci sono più opzioni là fuori . Assicurati di configurarlo per funzionare nel modo desiderato. Bloccare stili e script potrebbe non essere l'unica cosa che vuoi fare. Che mi dici degli iframes? Le forme? Collegamenti a strani protocolli?
Ora devi usarlo su tutto che inserisci nel DOM, ad es. utilizzando innerHTML() . Un modo per farlo è creare una nuova funzione da usare invece:
```
Element.prototype.secureInnerHTML = function(input) {
  this.innerHTML(mySanitizer(input));
}
```
Si noti che .textContent e .setAttribute() sono già sicuri, poiché operano direttamente sul DOM e non considerano l'input come una stringa di HTML. In generale, è buona norma utilizzare sempre .textContent quando il markup non è necessario.
Imposta una rigorosa norma di sicurezza del contenuto , non consentendo tutti gli script e gli stili inline.

Non sto dicendo che questo ti renderà sicuro al 100%, ma almeno è un buon inizio. Si noti che poiché abbiamo disattivato CSS in linea, tutti gli stili devono essere eseguiti utilizzando le classi. Se consentire l'uso di CSS in linea è un requisito, hai un problema molto più difficile da risolvere.