Since the URI has Alice's private info in the query string, Mallory's server can just save it and return whatever image it wants.
When the img element is created with Mallory's URI, the browser will attempt to load the "image" normally, since images are exempt from the Same Origin Policy. The Ajax call runs in Alice's browser, while Alice is logged on since the server does not know where the call comes from (main page or embedded page) it will do whatever it's asked to - including retrieving personal info. When Alice visits Mallory profile, and sees the animation, the script above runs: Performing an Ajax call to Facebook, using its API (say, Open Graph) the server will happily accept the call, since for all it knows the request came from a page with as origin.Ĭreate a URI pointing to her own server, with the returned data as query strings, and set it as the src of a picture in the sandboxed page. Mallory creates an "animation" that consists of: What would happen if Ajax calls weren't also blocked by default?
#IFRAME SANDBOX CODE#
It stores them in its own servers and, when displaying, sandboxes them as allow-scripts only (because scripts are needed for the animations to work) but leave everything else denied (in particular allow-same-origin, since you don't want user code messing up with the parent page). Let's make up an example: suppose Facebook decides to allow users post little HTML5 animations in their pages. The risk here primarily stems from user-generated content that is re-hosted in the IFRAME. It kind of makes sense that content on the same domain should be safe. Why is it so important to block Ajax calls from sandboxed contents from the same domain? As explained in the article: Note that, while both reported location.host as localhost, one considered the origin to be while the other considered it to be null (showing the same error message you experienced in your example). and if you embed it without allow-same-origin: localhost Origin is not allowed by Access-Control-Allow-Origin. If you embed the page above in an iframe with allow-same-origin it will print this to the console: localhost However, how it will fail will depend on the sandbox attribute used. If you try to make an Ajax call to a different domain, it will obviously fail: Since it doesn't make sense to make Ajax requests to null, sandboxed pages can not make Ajax calls at all (if making them to localhost were allowed they would be indistinguishable from the calls from the parent page, defeating the purpose of sandboxing). In other words, if you omit the allow-same-origin in the sandbox attribute, it will treat the sandboxed page as belonging to a different domain (in fact, it will treat as having a null origin). No other actions can be done inside the IFRAME that could compromise the hosting website or take advantage of the users’ trust. This means that even content coming from the same domain is treated with the cross-domain policy, as each IFRAME content will be viewed as a unique origin.Įmbedded content is only permitted to display information.
The content is not able to traverse the DOM or read cookie information. All content is treated under a unique origin. The reason it affects Ajax is because Ajax is governed by the Same Origin Policy rules, and when you sandbox it you're effectively telling the browser to treat the iframe contents as if it were from a different origin.
0 kommentar(er)
