LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This 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


Reply
  Search this Thread
Old 01-29-2020, 12:46 PM   #1
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
Browser-behavior on iframe content change


Good evening.

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.
 
Old 01-29-2020, 03:21 PM   #2
teckk
Senior Member
 
Registered: Oct 2004
Distribution: FreeBSD Arch
Posts: 3,262

Rep: Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979Reputation: 979
I'm not sure what you are wanting. If you don't want scripts to run in a browser then turn them off. Sorry I don't use Firefox or plugins.

I loaded the page with dillo, got a frame marker for
http://www.nepmso.lautre.net/accueil.html

That gets me another page in French with 2 objects
https://player.vimeo.com/video/373931342
https://player.vimeo.com/video/190220936

Code:
youtube-dl -F https://player.vimeo.com/video/373931342

[info] Available formats for 373931342:
format code                                   extension  resolution note
dash-akfire_interconnect_quic-audio-d6cce274  m4a        audio only DASH audio   64k , m4a_dash container, mp4a.40.2 (24000Hz)
dash-fastly_skyfire-audio-d6cce274            m4a        audio only DASH audio   64k , m4a_dash container, mp4a.40.2 (24000Hz)
dash-akfire_interconnect_quic-audio-dfb192e7  m4a        audio only DASH audio  128k , m4a_dash container, mp4a.40.2 (48000Hz)
dash-fastly_skyfire-audio-dfb192e7            m4a        audio only DASH audio  128k , m4a_dash container, mp4a.40.2 (48000Hz)
...
Quote:
Charging another page into the same <iframe/>
Can you explain a little more what than means?
 
Old 01-30-2020, 07:28 AM   #3
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
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 11:17 AM. Reason: Kraut2English, words and bad forebodings.
 
Old 02-11-2020, 03:50 AM   #4
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
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 03:51 AM. Reason: Too much sophistry.
 
Old 02-11-2020, 09:45 AM   #5
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.8.2003
Posts: 5,348

Rep: Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992
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.
 
1 members found this post helpful.
Old 02-11-2020, 12:57 PM   #6
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
Quote:
Originally Posted by scasey View Post
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 01:00 PM. Reason: words.
 
Old 02-11-2020, 01:02 PM   #7
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.8.2003
Posts: 5,348

Rep: Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992
Quote:
Originally Posted by Michael Uplawski View Post
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.
 
1 members found this post helpful.
Old 02-11-2020, 01:22 PM   #8
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
Quote:
Originally Posted by scasey View Post
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 01:24 PM. Reason: Lots of Buts removed... but that cannot be all but.
 
Old 02-11-2020, 04:56 PM   #9
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.8.2003
Posts: 5,348

Rep: Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992
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.
 
Old 02-11-2020, 06:30 PM   #10
boughtonp
Member
 
Registered: Feb 2007
Location: UK
Distribution: Debian
Posts: 955

Rep: Reputation: 735Reputation: 735Reputation: 735Reputation: 735Reputation: 735Reputation: 735Reputation: 735
I don't entirely understand the thread, but I think the issue boils down to: If you don't trust Vimeo, don't embed Vimeo resources on your page.


(And if you have JavaScript questions, I find adding "mdn" to my search queries gives the best chance to get the answer I'm looking for.)

 
Old 02-13-2020, 01:49 AM   #11
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
Quote:
Originally Posted by boughtonp View Post
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.
 
Old 02-13-2020, 02:21 AM   #12
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.8.2003
Posts: 5,348

Rep: Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992Reputation: 1992
Here's what I mean about w3schools:
go to https://www.w3schools.com/js/tryit.a...ts_body_onload
paste this code:
Code:
<!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.
 
1 members found this post helpful.
Old 02-13-2020, 10:18 AM   #13
boughtonp
Member
 
Registered: Feb 2007
Location: UK
Distribution: Debian
Posts: 955

Rep: Reputation: 735Reputation: 735Reputation: 735Reputation: 735Reputation: 735Reputation: 735Reputation: 735
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.

 
1 members found this post helpful.
Old 02-13-2020, 02:04 PM   #14
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
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.
 
Old 02-15-2020, 01:18 AM   #15
Michael Uplawski
Senior Member
 
Registered: Dec 2015
Location: Outside, most of the time.
Posts: 1,031

Original Poster
Blog Entries: 27

Rep: Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597Reputation: 597
Unsolved to be Solved.

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 01:21 AM. Reason: Words.
 
  


Reply

Tags
iframe, inline-frame, javascript, load page


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
A virus changed all my index files with iframe, how to remove that iframe line? Farman Linux - Security 10 07-16-2009 09:40 AM
force iframe content to remain in iframe? frieza Programming 1 09-17-2008 07:29 AM
Problem with iframe in Mozilla and Firefox ! Balakrishnan84 Programming 4 08-06-2007 12:22 AM
iframe woes ScottReed Programming 0 07-26-2007 12:04 PM
javascript - submit an iframe form AM1SHFURN1TURE Programming 1 09-23-2006 06:51 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 06:16 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration