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 <
) 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.