I've read about the cross-domain policy and the restrictions it has in terms of access when we don't have access to both parent and child domains in order to allow access.
However, I was wondering if I have access to parent page and not child page of the iframe is it still impossible to get the iframe to display all links within as href links like http://example.com and not example?
I've seen some scripts before but these are all server side and the links within the iframe are adjusted based on user's country so these scripts don't serve my purpose
All help appreciated
Related
I want to embed user provided HTML code in my website. The code will be self-contained, and will contain script and style tags. I am planning to block all network calls from the the provided HTML code by using Content Security Policy headers. The code will only be able to access standard libraries like jquery and other standard resources (the same will be specified in the CSP). I want to restrict any communication between the iframe content and the parent domain.
My plan is to use an <iframe> to embed the content. The user will give an input, and then on clicking a button, an iframe will be rendered with the given input snippet. It will be rendered inline with other content of the page.
I am concerned about the effect of this on the security of my website.
Can I make the origin of the iframe null? Or will I have to host my content on a separate domain so that SOP blocks all the network calls to the parent page?
Will I be able to set up CSP for the iframe separately? If yes, can anyone suggest what all attributes the CSP should have?
Can I take the input html and inject it directly to my iframe from the parent page?
If there are other alternatives which don't use iframe, which are those?
Can I make the origin of the iframe null? Or will I have to host my content on a separate domain so that SOP blocks all the network calls to the parent page?
You can make the origin of the iframe null if you'll use, for instance, a data:-Url. This will prevent cross-origin requests in modern browsers, but Content Security Policy of parent document will be inherited into iframe in all browsers.
In this case some old browsers (Firefox/WinXP) will spread CSP from the iframe to parent document too.
Will I be able to set up CSP for the iframe separately? If yes, can anyone suggest what all attributes the CSP should have?
You are able to set separate CSP for iframe only if it's loaded via network scheme (http:/https:) - it will be created isolated browsing context. If non-network schemes (data:, blob:, etc) iframe will inherit CSP of parent document.
In case of isolated browsing context you can use any "attributes the CSP" what you need for your specific case.
Pay attention to csp=, sandbox= attributes, these can be useful.
Can I take the input html and inject it directly to my iframe from the parent page?
This is contravert your statement: "I want to restrict any communication between the iframe content and the parent domain.".
Therefore all communications are possible via server only.
If there are other alternatives which don't use iframe, which are those?
Isolated browsing contexts can be created via <object>/<embed>, but these are not useful in your case.
I have a web page that will be embedded in iframes on multiple domains. I need to determine which domain is embedding my content.
document.referrer doesn't work, because I need the parent window, not the home page of the site or the page last visited prior to navigating to my page.
I don't have any control over the sites that are embedding my content.
Because of abuse over the years Web-browsers & servers have added security.
One of them being is preventing an iframe from accessing the parent Domain unless it meets the SAME ORIGIN POLICY.
https://en.wikipedia.org/wiki/Same-origin_policy
Now the HOST which your website will be embedded can allow access your to access the parent host. Something called CORS for short.
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Also check out.
https://en.wikipedia.org/wiki/Web_Messaging
Hope that answer your question some.
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
I'm designing some "add-on" to certain websites, which should be embedded in them as an iframe. Inside this iframe there is a clickable button aimed at changing the iframe's position within the parent website.
Since things are done in coordination with the parent website, I am able to add some code there as well. However it seems I am not able to do neither of the following (one of them should suffice):
From the iframe, access data within the parent.document, in order to move the iframe to the desired position.
From the parent website, access data within the iframe, in order to check when the button is clicked.
Both typically produce an error: "Blocked a frame with origin XXX from accessing a frame with origin YYY. Protocols, domains, and ports must match".
Any advice (preferably with code sample) is appreciated.
After doing lots of searching around, I came across this:
http://www.codeproject.com/Tips/585663/Communication-with-Cross-Domain-IFrame-A-Cross-Bro
I actually tested the method (using my own short piece of code) and it seemed to work on Chrome, Firefox and IE. Now I'm gonna try the "real" implementation...
From what I understand based on the information you've provided in your question, cross domain scripting is not possible. What you would need to do is provide a script that the parent-level website can paste into their template/html and run from their domain, similar to how Google does with their analytics system.
As an alternative, try turning your iframe content instead, into a div loaded with the response from a service call made from the parent domain to the iframe domain. You would most likely need to create an API that a requesting site can use. Simply call that URI with whatever parameters you would use when referencing the page you wanted to load in the iframe, and have the script that you run on the parent website handle all the DOM alterations you want to achieve.
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.