Is there a way of filtering the data of an iframe output?
For example I'll do an iframe on http://net.tutsplus.com/tutorials/python-tutorials/python-from-scratch-creating-a-dynamic-website/ and I only want to print the div with tutorial_image class. Is that possible?
Iframes sourced from other domains are subject to the Same Origin Policy - this prevents the host page from messing with them. This is a security feature that can be turned off in your browser settings -- but you cannot control this for other users.
Related
I'm trying to extract or just analyze the audio from a vimeo video with the web audio API and was wondering if it's possible and how.
Right now I get the error:
Uncaught TypeError: Failed to execute 'createMediaElementSource' on 'AudioContext': parameter 1 is not of type 'HTMLMediaElement'
… when I try a createMediaElementSource(video) where video is my iframe
Unfortunately I think it is not possible to do what you want. At least not exactly in the way you want it.
The createMediaElementSource() factory function only works with media elements. And those are only <audio/> and <video/> elements. This is why it doesn't work when you use it with the <iframe/> directly.
Normally you would query such a media element for example by its id like this:
document.querySelector('#myAudioElement');
But this is not that easy if the element is inside an <iframe/>. Then it is only possible to query an element if the <iframe/> and the parent document do have the same origin. This is because of the same-origin policy which is a security feature. Imagine what an attacker could do if it was possible to load any page in an <iframe/> and then modify it at will.
Of course it is a hindrance for your use case. Maybe building a browser extension is an option for you because they have usually more privileges and can query the DOM of any page the browser loads.
Alternatively it is also possible to disable the same-origin policy in some browsers. But that is usually only useful during development because you can only disable this policy for the whole browser which is a security problem unless you only open sites that you fully trust.
Would it compromise the security of a website if users were allowed to create img tags with whatever src attribute they wanted?
What kind of damage would be possible?
Allowing arbitrary src values on an <img> element would allow Cross-Site Scripting and thus the execution of arbitrary JavaScript code on your page:
<img src="javascript:…">
It could also be used to forge arbitrary GET requests, similar to Cross-Site Request Forgery but with a referrer originating from your site.
can also be exploited to track your website visitors by using a web bug http://en.wikipedia.org/wiki/Web_bug
I have a iframe in my webpage (facebook like etc.). can i prevent a break out from this iframe?
I did not the iframe can data be read at my session / forms etc
If you're worried about security: No need. An iframe containing an external page can not read sessions, or submit forms, in the parent page. The Same Origin Policy prevents that.
Other than that: Preventing frame busting is a complicated task. See this question for some of the complexities, and a working code example for a "frame buster buster".
I'm maintaining an application that goes sort of like this:
There is a Page A with a Frame that shows Page B. Now page B is part of a completely different product in a separate domain.
Now, they want that when an option in B is clicked, the WHOLE page is redirected to another page in A. The problem is that the url of A is something like www.client.A.com/Order/Details/123, and when we click in be it should redirect to something like www.client.A.com/Order/Edit/123 but B doesn't know anything about A. It doesn't know which order # is currently selected or anything about A. Page A who has the frame B does know it.
For now my solution has been to just redirect to the AllOrders so something like client.MyCompany/Orders
but since B doesn't know which client is calling it (its a multi-tenant app), I'll add it in the webconfig. (so each client has its own webconfig with a different value).
I dont find this solution optimal but I can't think of anything else! I already tried putting the needed url in page A in a hidden Div (since A does know all the info) and then trying to read the whole DOM of the page from B to find it.... unfortunately I can only get access to Frame B's DOM... (I tried with jquery).
I know frames are evil, but this is how it is written... any ideas?
Thanks!
If the parent page A and the iframe page B are in different domains, you will not be able to access methods or fields via B's parent property, nor will script in A be able to reach into B's content, nor will you be able to share global variables between A and B. This boundary placed between page A and page B is a key part of the browser security model. It's what prevents evil.com from wrapping your online bank web page and stealing your account info just by reading the internal variables of the javascript of the bank's web page.
If you have the luxury of requiring the latest generation of browsers, you can use the postmessage technique mentioned in one of the other answers here. If you need to support older browsers, you may be able to pass small amounts of information using cross-domain client scripting techniques in the browser. One example of this is to use iframes to communicate info between the outer page A and the inner page B. It's not easy and there are many steps involved, but it can be done. I wrote an article on this awhile ago.
You will not be able to monitor clicks in B's iframe from the parent page A. That's a violation of browser security policies at multiple levels. (Click hijacking, for one) You won't be able to see when B's URL changes - A can write to the iframe.src property to change the URL, but once the iframe.src points to a different domain than A's domain, A can no longer read the iframe.src property.
If A and B are in different subdomains of the same root domain, you may have an opportunity to "lower" the domain to a common root. For example, if the outer page A is hosted in subdomain A.foo.bar.com, and B is hosted in subdomain foo.bar.com, then you can lower the domain in page A to foo.bar.com (by assigning window.domain = "foo.bar.com" in A's script). Page A will then behave as a peer of page B and the two can then access each other's data as needed, even though A is technically being served from a different domain than B. I wrote an article on domain lowering, too.
Domain lowering can only peel off innermost subdomains to operate in the context of a root domain. You can't change A.foo.bar.com to abc.com.
There is also a slight risk in lowering domains to a common root domain. When you operate your page in its own subdomain, your html and script are segregated from the other subdomains off the common root domain. If a server in one of the other subdomains is compromised, it doesn't really affect your html page.
If you lower your page's domain to the common root domain, you are exposing your internals to script running on the common root domain and to script from other subdomains that has also lowered its domain to the common root. If a server in one of the other subdomains is compromised, it will have access to your script's internals and therefore it may have compromised your subdomain as well.
in case the page & frame are not on the same domain, you'll have to use postmessage as the same-domain policy prohibits normal javascript-communication between pages/frames of different domains because of security concerns.
postmessage is part of html5 and works in all modern browsers (including IE8). if you need support for older browsers (specifally IE6/7), you could use the jQuery postmessage plugin (which transparently falls back to some nice hash-tag trickery for older browsers).
and as a sidenote: not sure if frames are evil, there are some problems (usability, SEO, ...) related to them, but i did some research and most of these can be tackled i think.
If you want to communicate between frames in javascript you can use 'parent':
If frame A has a variable value, eg:
var orderNo = 2;
For frame B to read it it would refer to
var frameA_orderNo = parent.frames[0].orderNo;
(assuming that frame A is the first frame declared)
So you can set up global variables within each frame that the other frame can read and therefore you can get the order # in old fashioned javascript (never tried it in jquery).
Wow frames - never thought I'd think about them again.
I have a problem where I have a frameset consisting of a parent frame loaded from one domain and a contained frame from a different domain. The contained domain also sets a cookie before the frameset is loaded. However, because of the 'same orgin' policy, enforced by most browsers, a contained frame will not pass cookies if it is not from the same domain as the parent.
Unfortunately I have no control over the parent frame (or its url) and the url for the contained frame is effectively static. So the only way to pass information to the contained site is via cookies.
The only solution I have come up with is to reload the contained domain in the parent frame but this negates some of the value of using frames in the first place.
Does anyone have a better work around for this problem?
There are a couple of methods of getting around the Same Origin Policy that is preventing your iframes from speaking to each other. If you control both servers then you can use Flash's crossdomain.xml file. If you don't control one of the servers or you would like to use JavaScript, then you are forced to use a "Cross-Domain Proxy", such as this one for java or python or php.
Cross-Site XHR is another option but it isn't supported by all browsers.
There are a lot of ways to do this. Here are two that I've used:
Have both the parent and child load
a script from a common source, using
a tag. Scripts loaded in
this way don't have same-origin
issues, and the data they return
becomes part of the document object
and can interact with other scripts
loaded by the document (this is the
way that AJAST works).
Create a reverse proxy in the parent domain, and load the frame via this proxy. To the browser, it appears that they're both served from the same domain. The downside is that this can affect caching, and bypasses any content delivery network (eg, Akamai) that you might be using.
There is also a right way of doing this in HTML 5 with postMessage.
See here: http://ajaxian.com/archives/cross-window-messaging-with-html-5-postmessage
One more thought in to this, where u can use Cross Domain Messaging API to send messages from one frame to another. here is an example! Read more on this.