[SOLVED] Browser-behavior on iframe content change
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is about JavaScript and possibly ill-placed in this forum. But I am at a loss and unable to evaluate this.
Scenario: One local page, loaded in an <iframe/>, contains references to videos somewhere on the Web. The video-site is vimeo.com and logically their JavaScript-routines are loaded with the references to their player.
The page is here: www.nepmso.lautre.net
Initially a page accueil.html is loaded into the <iframe/>. This is where you see the videos (scroll the frame, if not).
Charging another page into the same <iframe/>, it looks like the JavaScript from the foreign site remains active. At least, the Noscript extension to Firefox or Torbrowser indicate that it is.
Questions: If this is normal and understandable to you, PSE try to explain it to me, too. Is there a way to change the behavior and avoid that JavaScript routines “survive” upon loading a different page into the <iframe/>?
Or maybe Noscript is fooling me as none of this makes sense.
My resolution to stay away from LQ conflicts with the number of search-results I get on this topic: 0. This must be because I use the wrong criteria or do not get anything right anyway. So be patient with me once again.
I try to re-formulate my initial post, but cannot promise that it will produce different problems... or fewer.
The decision to use an <iframe/> came from the experience with a previous version of the same site, which asked for more maintenance. The iframe turns out to be more “generator-friendly”, at least as my own generator-scripts are concerned.
So, in consequence, navigation on the site, from one page to another, is in reality replaced by “charging a page into the iframe” on index.html. The difference is probably marginal. You could say that you never move away from index.html and that only the content of the <iframe/> element changes. I don't, as these nuances are difficult to prove without knowing what the browser really does and, as I said, it does not matter.
Now what happens is this: one of those pages which are “charged into the iframe” demands that java-script routines be loaded, too. They are.
But if I “move away” from there and replace the <iframe/> content against that from another page, the java-script routines appear to persist ... somewhere, cache, memory... somewhere where noscript is looking for them.
What I would have expected and what I would deem right, correct, best ever (if need be), is that each page loaded into the iframe brings its own script-routines or none, but that those from the previously visited page do not longer matter-, that I am assured that none of those previously loaded routines are lurking somewhere, be there work for them to do or not.
My expected result of this inquiry is that I am missing the point. What I hope for is advice to correct the behavior of the “entity” concerned, either the web-site or the browser in use. Luxury would be that I actually comprehend what is going on, but I do not dwell on that, it is not a requirement.
Last remark: All that I describe is independent of my choice to allow or to disallow execution of whichever script.
Last edited by Michael Uplawski; 01-30-2020 at 10:17 AM.
Reason: Kraut2English, words and bad forebodings.
I am reviving this thread for the simple fact that I have no answer. Not that I obliged you to ponder uninteresting questions... but anybody who hopes to find insight from other resources on the Web should know that downright despair can be the only attitude to adopt, for now.
Last edited by Michael Uplawski; 02-11-2020 at 02:51 AM.
Reason: Too much sophistry.
I would expect the JavaScript to behave as you describe. JavaScript is executed client-side and is acts on the DOM of the window in which it is loaded. If the entire page is not reloaded, the script is going to continue to be available.
That shouldn't matter, however, if the content loaded doesn't actually call/run the script.
If the entire page is not reloaded, the script is going to continue to be available.
The “entire page” being the outer page that includes the iframe with whatever may be the default content. I understand this.
Quote:
That shouldn't matter, however, if the content loaded doesn't actually call/run the script.
Yes. Let us assume that I am a Paranoia-shaken sniveler... What if the script knows that every iframe has an onload handler? Well I know, so anybody can. But now that I mention it, I should try it out, myself. Do not bother.
Last edited by Michael Uplawski; 02-11-2020 at 12:00 PM.
Reason: words.
Yes. Let us assume that I am a Paranoia-shaken sniveler... What if the script knows that every iframe has an onload handler? Well I know, so anybody can. But now that I mention it, I should try it out, myself. Do not bother.
It’s not what the script “knows”, it’s what the onLoad calls/runs.
It’s not what the script “knows”, it’s what the onLoad calls/runs.
Exactly. I just tried to set onload-handlers programmatically (in a script). As the iframe is part of the “outer” page, the onload-handler should stay functional after being set.
I am unable to make this exploit run, which does not convince me; but I guessed that it would not be that trivial.
Thank you scasey. This is stuff that I should have stumbled upon, before, but I have never had use for iframes.
Last edited by Michael Uplawski; 02-11-2020 at 12:24 PM.
Reason: Lots of Buts removed... but that cannot be all but.
Glad to have been of some help. Intuitively, I don't think onLoad would fire except at reload of the parent window, but I'd have to dig thru documentation of the DOM to be sure of that. The documentation at w3schools.com is excellent...well worth perusing.
TY boughtonp, but my question is neither on vimeo, whom I trust, nor JavaScript as a language. I just want to make sure that no script survives when the content of an iframe changes. As far as scasey has succeeded in clarifying things, the iframe adds complexity that I have not taken into consideration, so far.
Now the question has evolved into: Would a dynamically set onLoad-handler act on the iframe content, while scripts originating from the previous content are still present in memory?
The situation occurs too often since browsers support iframes, so the answer must be “probably not”. But that is just deduction and belief.
If there is a way to “harden” my iframe against a possible exploit like this, I want to know it anyway... e.g. setting my own onload-handler as soon as its definition changes or the like.
<!DOCTYPE html>
<html>
<head>
<script>
function myFunction() {
alert("Page is loaded");
}
function myFunction1() {
alert("Iframe is loaded");
}
</script>
</head>
<body onload="myFunction()">
<h2>Hello World!</h2>
<iframe>
<html>
<head></head>
<body onload="myFunction1()">
<h2> Whatssup? </h2>
</body>
</html>
</iframe>
</body>
</html>
and run it. As you will see, the onload in the frame doesn't fire (but then, the iframe is empty too, so I'm not sure what's going on there).
Anyway, you can paste your code directly on that page and see what happens.
I did note that the onload does fire if attached to the iframe tag instead of the body tag, so it depends upon what event the onload is triggered by.
I'm still not sure I get what you're asking - for me, scripts outliving/escaping their container is a security concern and/or a memory concern.
Quote:
If there is a way to “harden” my iframe against a possible exploit like this...
If you're asking about a possible exploit, then it's a security matter, and that's where trust comes into it.
Quote:
... e.g. setting my own onload-handler as soon as its definition changes or the like.
If there is an issue, the most likely solution would probably be to use the sandbox attribute to apply all restrictions (which should prevent scripts running), then navigate to the new location, and then re-allow only the necessary.
But if you really want to understand what's going on and what can/can't be done with iframes, I suspect the best source of information (short of reading browser source code) would be to ask the authors of plugins like uBlock Origin or NoScript.
Yes, I think this thread showed that the issue cannot be handled in the way I hoped for. And as a lack of knowledge is clearly the origin of my insecurity, I shall rectify that first.
TY for your time. I [solve] this issue now, as whatever can follow, would anyway no longer fit under my original post. A blog-post may be more suitable in case that what I learn about iframes, onload and dynamically set event-handlers can be bundled up that way.
I have a bookmark for the tryit editor and TY for the sandbox attribute.
The answer to my original question is probably this:
Quote:
SecurityError: Permission denied to access property "document" on cross-origin object default.html:10
There is a Wikipedia article on Cross-origin resource sharing, which helps understand what
is going on
can be done
It boils down to “Know what you do” and “Do not do, what you do not know to do” or put in yet another way:
If I want to allow code to work on arbitrary content of an IFrame, I have to say so. Else it is not allowed. Browsers are partly responsible but their adherence to a standard can be assumed.
As regards this very thread, I have to admit that my limited English vocabulary is responsible for much of my insecurity, because I have simply not considered cross-site-scripting (-attacks) as closely related. Thus my researches on the All-Knowing Trash-Heap were ill-directed.
How can I convey the message. This is an issue in all my inquiries on this forum.
Last edited by Michael Uplawski; 02-15-2020 at 12:21 AM.
Reason: Words.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.