Il CSP è sufficiente per prevenire attacchi XSS [duplicato]

3

Supponendo che gli utenti stiano utilizzando browser moderni, sta implementando una policy CSP severa quanto basta per prevenire tutti gli attacchi XSS?

Sto lavorando a un'app Backbone e mi chiedo se devo ancora visualizzare i dati degli utenti di escape sul client per visualizzarli tutto il tempo.

    
posta Akshay Rawat 22.04.2015 - 12:16
fonte

3 risposte

1

Assuming that users are using modern browsers, is implementing a strict CSP policy enough to prevent all XSS attacks?

Non tutti i browser moderni implementano CSP (IE ha solo un supporto molto limitato). Ma partendo dal presupposto che il browser abbia il supporto CSP corretto e che il CSP sia molto severo (nessuna valutazione non sicura!), Allora può essere usato per prevenire con successo l'XSS. Ma ...

I'm working on a Backbone app, and am wondering if I still need to be escape user data on the client to display all the time.

Ci sono altri attacchi oltre all'XSS. Se non esci correttamente, l'iniezione HTML può ancora essere utilizzata per influenzare le parti della pagina che non sono coperte da CSP, come:

  • Includi collegamenti ( <a href=... ) che puntano alle risorse controllate dagli autori di attacchi. A seconda della pagina, i collegamenti esistenti potrebbero essere modificati.
  • Includi nuovi moduli o modifica l'obiettivo di invio per i moduli esistenti. In questo modo puoi acquisire dati sensibili.
  • Reindirizza l'utente ai download drive-by includendo l'HTML utilizzando il meta refresh
  • un altro possibile
risposta data 22.04.2015 - 19:05
fonte
1

Content Security Policy (CSP) è solo un livello di sicurezza che aiuta a rilevare e mitigare alcuni tipi di attacchi, tra cui Cross Site Scripting (XSS) e attacchi di data injection. Tuttavia, tieni presente che la sicurezza riguarda la difesa in profondità , quindi è necessario implementare ulteriori livelli di sicurezza e ricorda che la prevenzione delle vulnerabilità Cross-site Scripting Attacks (XSS) in tutte le lingue richiede due considerazioni principali :

  • il tipo di sanitizzazione eseguita sull'input
  • posizione in cui è inserito quell'input.

È importante ricordare che non importa quanto bene l'input sia filtrato; non esiste un unico metodo di sanitizzazione che possa impedire tutto il Cross-site Scripting (XSS).

Il filtraggio richiesto dipende in larga misura dal contesto in cui i dati sono inseriti. Prevenire l'XSS con dati inseriti tra elementi HTML è molto semplice. D'altro canto, prevenire l'XSS con i dati inseriti direttamente nel codice JavaScript è molto più difficile e talvolta impossibile.

Per la maggior parte delle applicazioni PHP, htmlspecialchars () sarà il tuo migliore amico. htmlspecialchars () fornito senza argomenti convertirà caratteri speciali in entità HTML.

Esiste un'altra funzione che è quasi identica a htmlspecialchars (). htmlenities () esegue la stessa disinfezione funzionale su personaggi pericolosi, tuttavia codifica tutte le entità di carattere quando ne è disponibile una.

strip_tags () non deve essere utilizzato esclusivamente per la sanitizzazione dei dati. strip_tags () rimuove il contenuto tra tag HTML e non può impedire che esistano istanze XSS all'interno di attributi di entità HTML. anche strip_tags () non filtra o codifica parentesi angolari di chiusura non accoppiate. Un utente malintenzionato potrebbe combinare questo con altri punti deboli per inserire JavaScript completamente funzionale nella pagina.

addslashes () è spesso usato per sfuggire all'input quando inserito nelle variabili JavaScript.

    
risposta data 22.04.2015 - 12:54
fonte
0

No - questo è in parte dovuto al supporto del browser. Ad esempio, Internet Explorer supporta solo parzialmente i criteri di sicurezza dei contenuti .

Inoltre, un CSP dovrebbe essere visto come una soluzione secondaria efficace per XSS. Consideralo come una protezione contro il codice in cui lo sviluppatore si è dimenticato di codificare l'output correttamente. Ciò proteggerà la tua applicazione nei browser supportati mentre la correzione viene creata e prima che venga distribuita ai tuoi sistemi di produzione.

La corretta codifica dell'output garantisce che vengano seguiti gli standard Web, il che aumenta sia la sicurezza che la funzionalità. Ad esempio, non vorrai che la tua applicazione web venga visualizzata in modo errato se l'utente ha deciso di inserire <> caratteri nel suo input.

Inoltre, potrebbe essere possibile per utenti malintenzionati interrompere il tuo sito in altri modi, nonostante il CSP. Ad esempio, includendo altri script da fonti consentite o includendo gli script due volte per creare un Denial of Service per gli altri utenti in cui viene visualizzato l'output (poiché il duplicato interrompe la logica della pagina). Un utente malintenzionato potrebbe anche modificare il contenuto del tuo sito in altri modi.

In sintesi vorrei sconsigliare l'uso di funzionalità di sicurezza aggiuntive al fine di tagliare le curve altrove. Dovrebbero essere gratuiti - pensa sempre difesa in profondità .

    
risposta data 22.04.2015 - 12:50
fonte

Leggi altre domande sui tag