Fracture de trame uniquement inter-domaine mais pas pour les iframes de la même origine?

Question

Cette question était auparavant asked and answered correctement, mais il ne semblait pas y avoir de solution postée.

Si un site a iframes, et veut empêcher ceux d'être enfermé dans un cadre d'un autre domaine, cadre busting simpliste ne sera pas utile:

<script>if (top != self) top.location = location</script> 

Cependant, depuis les scripts inter-cadres à d'autres domaines devraient générer des exceptions, quelque chose comme cela semble bien fonctionner à l'intérieur de l'iframe:

<script> 
try { 
    if (window.document.domain != top.document.domain) { // throws exception 
    throw "You naughty puppy!"; // Should not ever get here, right? 
    } 
} 
catch() { 
    top.location = "/error/naughtypuppy"; 
} 
</script> 

le if ci-dessus devrait être assez seul pour empêcher le cadrage inter-domaines des iframes. Il devrait seulement retourner false ou lancer une exception, alors de toute façon le script pourrait atteindre l'instruction throw dans un navigateur?

Est-ce que cela suffirait à empêcher le tramage uniquement à partir d'autres domaines?

<script> 
try { 
    var bogus = top.document.domain; 
} 
catch() { 
    top.location = "/error/naughtypuppy"; 
} 
</script> 

Edit: Une solution similaire est fait allusion ici, mais on ne se baserait pas sur le cadre parent d'inclure le code de cadre busting. Detect when iframe is cross-domain, then bust out of it. Essentiellement la même solution que "essayer d'accéder à l'autre image et bust si une exception se produit."

Answer 1

Ce code est vulnérable à une forme d'attaque qui tire parti de la fonction « onbeforeunload ». La page parent (evil) configure un gestionnaire d'intervalle (qui est invulnérable à votre code, en raison de la différence de domaine) et un gestionnaire "onbeforeunload". Le deuxième gestionnaire met à jour juste une variable globale (également invulnérable) pour enregistrer le fait que la fenêtre est "attaquée", puis le temporisateur d'intervalle (s'exécutant assez rapidement pour pouvoir être actif avant que le navigateur ait complété la fenêtre externe mise à jour à votre URL légitime) apparaît et met à jour window.location pour pointer vers une URL contrôlée par l'attaquant qui renvoie une réponse no-op 204. Le navigateur oublie votre requête HTTP et "met à jour" la fenêtre à partir de cette nouvelle transaction initiée par le gestionnaire d'intervalle.

est ici le plus SO question: Frame Buster Buster ... buster code needed

Answer 2

J'ai un site qui a encore des cadres et je ne peux pas les enlever pour l'instant. Ce fut la meilleure solution que j'ai pu trouver:

<style>html { display:none }</style> 
<script> 
if (self == top) { 
    document.documentElement.style.display = 'block'; 
} else { 
    top.location = self.location; 
} 
</script> 

A partir de ce lien: XFS 101-cross-frame-scripting-explained

Sur la base d'une présentation de: OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt

Voici un plus mis à jour OWASP Clickjacking page