Queste quattro protezioni di intestazioni HTTP sono sufficienti per lo scripting cross-frame?

3

Vorrei fare una domanda qual è la migliore protezione contro Cross-Frame Scripting.

Ho configurato il mio server web per aggiungere questi flag in HTTP HEADER:

X-Same-Domain: 1
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

È abbastanza? O c'è più protezione che potrebbe essere utilizzata?
La mia applicazione Web è in esecuzione su IIS.

    
posta Jamie 15.09.2015 - 08:24
fonte

2 risposte

2

Una risposta: No.

Questo è un buon inizio ma queste intestazioni sono indicatori per i filtri e motori Anti-XSS che sono incorporati dai browser moderni. Si tratta di una protezione molto fragile e sottile contro Cross-Site Scripting (XSS). Un utente malintenzionato può facilmente aggirarlo.

Per rendere la tua applicazione completamente blindata e protetta contro XSS, ti consiglio comunque di utilizzare il filtro ValidateRequest di ASP.NET insieme a un filtro personalizzato a livello di applicazione che codifica caratteri speciali in tutte le richieste.

L'applicazione non dovrebbe accettare alcuno script, carattere speciale o HTML nei campi quando non richiesto. Dovrebbe sfuggire a caratteri speciali che potrebbero rivelarsi dannosi. I caratteri possono essere sfuggiti secondo l'elenco disponibile a questo link:

risposta data 15.09.2015 - 08:41
fonte
1

Lo scripting cross-frame non è un termine che ho visto prima. Da quello che ho letto, sembra che si tratti di un sottoinsieme di XSS (Cross-site scripting) che utilizza fotogrammi iniettati. Il blocco dello scripting cross-site dovrebbe essere la priorità principale. I comportamenti critici da proteggere contro XSS sono la codifica dell'output (qualsiasi cosa che possa essere controllata dall'utente viene sfuggita o codificata in entità prima di essere inclusa nella risposta, ad esempio, un segno < in un contesto HTML deve essere convertito in &lt; ) e la convalida dell'input (non consentire agli utenti di inserire tipi di valori che non corrispondono al formato e ai caratteri previsti per ciascun campo).

Se si desidera una protezione basata su intestazione contro XSS, la soluzione è Content Security Policy , che limita le fonti di tutti tipi di contenuto potenzialmente dannoso (solitamente incentrato su script e fogli di stile, ma supporta anche la limitazione dei frame). Utilizzato correttamente, CSP è una protezione estremamente potente, ma gli utenti che utilizzano vecchi browser (comprese tutte le versioni di IE) non saranno protetti da esso (sebbene Microsoft Edge lo supporti, o lo dimenticherò presto). Nota che l'uso corretto del CSP potrebbe richiedere alcuni refactoring del tuo sito, spostare tutti gli script, ecc. Nei propri file invece di consentire lo script inline.

Per proteggersi dal fatto che il tuo sito venga incorniciato da un utente malintenzionato, l'intestazione X-Frame-Options è la soluzione ideale per proteggere tutto tranne i browser estremamente vecchi (ad esempio IE6). In generale, usa DENY anziché SAMEORIGIN a meno che tu non abbia una ragione specifica per usare SAMEORIGIN ; in realtà non è un limite di sicurezza aggiuntivo, ma può rendere più difficili alcuni tipi di attacchi.

    
risposta data 15.09.2015 - 09:19
fonte

Leggi altre domande sui tag