This MSDN article explains that READS are not permitted by the same-origin policy.
Specifically, it says:
Webpage from Origin A:
May include (execute) a frame pointed at a HTML page from “B”
Must not be permitted to get the inner HTML of that frame
How can another html file be "included (executed)", without the content of it being accessed?
What does "included (executed)" even mean in this context?
This is referring to the fact that the user viewing the page can see the content of the iframe, but scripts running on the framing page cannot access the content of the framed page. Consider analogously that an <img> tag will show an image from any origin to a user, but scripts within the page that contains the <img> tag might not be able to read the contents of the loaded image.
This is important because the framed page is from a different origin and was fetched using the user's cookies from that origin. Suppose the framed page was mail.google.com: certainly I don't want any random webpage to read the contents of my inbox simply by loading it in an iframe. However, merely showing the page to me, the user who happens to be logged in to my mail service, is harmless.
Related
I'm loading an external domain site in an iFrame. I'm trying to monitor any url changes within that I frame and its location. I know there is a restriction with 'Same Origin Policy'. In chrome I can left click on an iFrame and select "view frame source" to view the html and other data. Is there anyway to do this with javascript in conjunction with Chrome?
I tried to monitor the url through iframe.src however that property does not update on url change.
This is the iFrame I am using. Which I can view a change event via an onload function.
<iframe src="https://en.wikipedia.org/wiki/Porsche_911" frameborder="0" onload="monitor ">
https://codepen.io/anon/pen/xWaGNx?editors=1111
This is not possible unless you have some kind of CORS (Cross Origin Resource Sharing) arrangement with the source domain (they would need to white list your domain in the appropriate HTTP header).
CORS prevents access to the content of documents that come from another domain. This is for security reasons. Otherwise, what would prevent you from framing the secure login page of some bank, but modifying the code on it to send you the access details?
I have a top page which contains an iframe with untrusted content. I am hosting the untrusted content on a domain that I control, and can (in theory) make changes to it. Short of analyzing the source code with something like Google Caja, is there any way that I can prevent the untrusted content from navigating the frame itself to other URLs? (or ideally restrict it to the trusted domain)
Related, but not quite:
Only addresses anchor tags, not navigation in general
Lots and lots of webpages talking about sandbox with "allow-top-navigation". Doesn't help because I want to restrict navigation of the frame itself
Background: My goal is to allow untrusted content to run in the iframe and to pass some user data to it, but I don't want the untrusted content to turn around and send this data to a 3rd-party. (The content will be allowed instead to postMessage any results to an API exposed by the parent window.) Content Security Policy HTTP headers on the untrusted content allow me to restrict all manner of network requests except navigation.
I randomly saw this new Content Security Policy option hinted at on MDN (with a little flask on it, so may still be experimental...)
navigation-to
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
What I want to do is open an iframe, pointing to another website, and then submit a form on that website.
This is obviously cross-origin, so Chrome (and I assume other browsers) doesn't allow me to do stuff to the contents of the iframe, once it's loaded.
So I've tried doing it in a Chrome extension. I'm getting a similar error:
Uncaught SecurityError: Blocked a frame with origin "chrome-extension://amnacjaocbabmgfjcbmgbhikfedaanmo" from accessing a frame with origin "http://www.example.com". The frame requesting access has a protocol of "chrome-extension", the frame being accessed has a protocol of "http". Protocols must match.
Any suggestions on how to make this work? I can post more details on my current method, if necessary. But, I'm open to other suggestions (e.g. opening a new tab and doing the work in there, etc.). Anyone know of something that will work without getting some kind of security error?
EDIT: So far the best solution I've come up with is using a background script to open a new tab, and use content scripts to manipulate its content. It would be really nice if I could just load the page into an iframe, and then send content scripts just to that iframe, but I haven't figured out how to do that.
In the page header of your embedded page, include the following header:
X-Frame-Options: ALLOW-FROM www.example.com
This bypasses at least Chrome and Firefox. Your mileage may vary on IE.
I'm loading a webpage inside iframe of a background page in chrome extension. I need to fetch the content (i.e. DOM) of iframe. I'm getting protocol error. how to overcome this situation, any workaround.
"Unsafe JavaScript attempt to access frame with URL https://swym.3ds.com/ from frame with URL chrome-extension://ohhaffjbbhlfbbpcdcajbkeippadmipk/back.html. The frame requesting access has a protocol of 'chrome-extension', the frame being accessed has a protocol of 'https'. Protocols must match."
I'm trying to implement a desktop notification for the above site, hiding the process from user eye.
I tried using XMLHTTPRequest and Jquery GET, unfortunately my site loading is unstandard, it doesn't work as intended.
Any suggestion on this topic will be very helpful.
It seems you're facing Cross-origin resource sharing issues. Do a quick check for resources loaded with protocols, convert http://www.example.com resources to //www.example.com Also refer MDN CORS Article
Javascript cannot access content on another domain as it poses security risks. If you have control over the domains, you may use postMessage to overcome this. Take a look at this link
Here's the situation: there is a site, and it belongs to the client, so it's not on my domain, lets say client.com.
On this site there is an iframe, the source of this iframe is a simple js code, which loads another js (client.js) - this code is on my domain.
What I need to do is to get the exact url of the page where the iframe is. So now I'm trying to fugure out the difference between document.referrer and window.parent.location.href with no luck.
Both give me exactly what I need, but I can't realize what is more reliable? Is there a situation, where one will work and another won't?
document.referrer gives you the URI of the page that linked to the current page. This is a value that's available for all pages, not just frames.
window.parent gives you the parent frame, and its location is its URI.
If you want to find the URI of the parent frame, then use window.parent.location.
The main difference is that the document.referrer will point to the page which linked to the current page inside the iframe. If your iframe content contain links, which allows to navigate through a few pages, then only the first page loaded inside the iframe will have parent frame URI as document.referrer.
Each page loaded by clicking link inside the iframe will have the uri of the page containing link in the document.referrer.
At the same time window.parent.location will always contain the URI of the page in parent window, but it will be accessible only if the site origin is the same.
Read about relaxing site origin policy to see what should be done on both your and your client sites, so you can access the data.
That being said, I would rather give your client something like a service key or token, which will authorize his site to use your iframed app, and which will authenticate the caller as your client, so you can know that the call is from his site.
"document.location.ancestorOrigins" is more feasible option.