L'attributo Security è stato implementato per prevenire gli attacchi XSS in iFrame disabilitando qualsiasi JS implementato nell'origine iFrame, quindi eliminando gli attacchi XSS, ma disabilitando anche qualsiasi script di sicurezza come frame busters, killers & ecc.
Ad esempio, qui ci sono tre pagine:
Pagina delle vittime
<html>
<head>
<script type="text/javascript">
if(top != self) top.location.replace(location);
</script>
</head>
<body bgcolor="red">
<img src="kitten.jpg" width="100%" height="100%">
</body>
</html>
Questa pagina contiene un frame buster molto scarso, ma abbastanza buono per questa dimostrazione. Nel caso in cui la pagina non sia il frame superiore nella sua finestra, reindirizza la finestra al percorso della pagina.
Pagina A
<html>
<body>
<center><iframe src="noIFrame.htm" border=1> </center>
</body>
</html>
Questa pagina contiene un esempio, cosa succede quando l'utente malintenzionato aggiunge la pagina usando iframe, senza abilitare l'attributo di sicurezza. Il risultato dell'apertura di questa pagina è una rapida occhiata alla pagina click jackers e quindi al reindirizzamento del browser al percorso della pagina.
Pagina B
<html>
<body>
<center><iframe src="noIFrame.htm" security="restricted" border=1></center>
</body>
</html>
Infine, questa pagina mostra l'implementazione dell'attributo di sicurezza. L'iFrame è caricato e, poiché l'attributo è impostato per limitare lo script di busting del frame, non sta reindirizzando il browser al percorso della pagina delle vittime. Nota che questo attacco è valido solo in IE8 e versioni successive.
Ora, supponendo che un utente malintenzionato possa caricare file sul web server delle vittime *, disabilitando il possibile utilizzo di X-Frame-Options, in che modo la vittima può proteggere il suo sito web da attacchi di tipo click contro i suoi utenti di IE? / p>
* Questa è una domanda ipotetica, ovviamente se l'attaccante ha accesso al dominio del server web che attaccherebbe in modo diverso.