Pourquoi un enfant peut-il rediriger un cadre parent?

La réponse à pourquoi c'est possible est parfaitement simple. window.location fait partie de l' API Web , ce qui n'est pas exactement le même que le noyau JavaScript. Cela fait partie de l' interface DOM , donc c'est gouverné par W3C, pas ECMA. C'est pourquoi il vous permet de manipuler les propriétés de la fenêtre supérieure.

À strictement parler, JS n'est pas capable de le faire, car il manque de fonctionnalités IO, ce qui rend la langue extrêmement portable. C'est pourquoi les implémentations du navigateur nécessitent l'API DOM, pour interroger le DOM, et demander des pièces de rechange ou interagir avec le client. Le DOM, cependant, a besoin d'IO, car il permet de lire et de lire à partir de l'interface utilisateur réelle. Certaines personnes dans le comité ECMAScript auraient plutôt vu l'accès à la window.top fortement restreints, sinon supprimés ensemble, pour des raisons de vulnérabilité XSS. Malheureusement, le W3C a accepté de ne pas être d'accord et a mis en place la référence window.top toute façon.
Qui a raison ou faillite dans ce cas? Je ne sais pas, il est facile de rediriger un client vers un site malveillant à partir d'un iFrame, ce qui n'est pas sécurisé. Mais il serait frustrant d'avoir un iFrame, puis de ne pas avoir accès à la fenêtre supérieure, ce qui signifie ne pas pouvoir interagir avec le client aussi facilement. Mais ce n'est pas le cas ici. En bout de ligne, vous pouvez modifier certaines propriétés de la fenêtre supérieure, et cela peut être utile. Il suffit de penser à mashups . Ils posent de nombreux défis en matière de sécurité XSS, mais ouvrent beaucoup de possibilités nouvelles et passionnantes pour les sites Web. Pour brancher certaines des vulnérabilités XSS les plus dangereuses, regardez ADSafe , créé par Douglas Crockford. Google a une lib similaire, mais j'ai oublié son nom ATM …

La même politique d'origine ne s'applique pas non plus ici. En changeant l'url dans la barre d'adresse dans la fenêtre de votre navigateur, vous modifiez également la propriété window.top.location.href . S'il y avait des restrictions d'origine même, Internet serait mort. Vous n'êtes pas en train d'envoyer une demande à un autre emplacement, vous n'obtenez pas les données d'une ressource tierce et vous la chargez dans votre page, vous redirigez le navigateur vers un autre emplacement, qui ferme et efface le DOM.

Je suppose que c'est la même raison pour laquelle vous pouvez faire ce qui suit:

 <a href="http://google.com" target="_top">Redirect top to Google</a> 

J'ai trouvé les règles pour ce comportement ici: http://www.w3.org/TR/html5/browsers.html#valid-browsing-context-name-or-keyword

Je ne pouvais pas trouver un «pourquoi», mais personnellement, j'ai trouvé utile de rediriger le parent après que quelqu'un a cliqué sur quelque chose dans un iframe. Vous voudrez peut-être d'abord effectuer une opération asynchrone et valider quelque chose avant de rediriger la page entière. Comme cela est déjà possible en utilisant la balise <a> cela a également été jugé approprié dans JS. Je ne sais pas pourquoi la balise <a> permet la fonctionnalité.

Cela étant dit, vous pouvez toujours éviter ce comportement en ajoutant l'attribut sandbox="" , par exemple: http://jsfiddle.net/ppkzS/1/

Chaque fois que vous utilisez des iframes , des frames ou des objects , vous configurez une hiérarchie de Windows, ces objets agissant comme des "fenêtres" dans cette hiérarchie.

Vous pouvez traverser cette hiérarchie avec des propriétés telles que .parent , .frameElement et similaires. La propriété .top est la fenêtre au point le plus élevé de la hiérarchie et correspond généralement au cadre le plus à l'extérieur.

Certaines actions sont interdites entre Windows dans la hiérarchie, d'autres ne le sont pas. La modification de l' location d'une fenêtre n'est pas interdite.

En fin de compte, les gens qui disent que vous ne pouvez pas le faire sont incorrects. Ce que vous ne pouvez pas faire, c'est d'accéder au contenu d'une fenêtre à partir d'une fenêtre différente si leurs domaines diffèrent. Toutefois, vous pouvez modifier leurs propriétés de localisation.

Si vous avez deux images sur le même domaine (et également le même protocole et le port aussi), un cadre peut rediriger l'autre vers où vous voulez, et accéder aux propriétés javascript, exécuter la fonction de l'autre image, etc.

Si vous redirigez un cadre de l'autre vers un autre domaine (ou un protocole ou un port), vous perdriez la capacité de faire tout ce que j'ai déclaré précédemment en raison de la même politique d'origine , mais la redirection elle-même est permise car, avant la redirection , Les deux cadres ont satisfait cette politique.

Voici des informations utiles: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript

Citation de cette page:

Deux pages ont la même origine si le protocole, le port (si l'une est spécifiée) et l'hôte sont les mêmes pour les deux pages.

De toute évidence, les frames sont identiques aux pages .