Re: [edbrowse-dev] interwindow bleed

[Adam Thompson <arthompson1990@gmail.com>]

On Thu, Nov 05, 2020 at 11:22:57PM -0500, Karl Dahlke wrote:
> Guys - really?
> We've had this architecture for over 2 years and none of you called me on it?
> None of you said,
> 
> "Ok Karl, it's more efficient, but there's a security hole big enough to drive a truck through!"
> 
> We compile our dom in the master window, mw0, just once, not every window every time, saves time, saves memory, saves resources, ok fine, but,
> then stop for 5 minutes and think what someone can do.
> Write your own appendChild function that calls mine, by making a copy of mw0.appendChild, then put yours in its place.
> Since yours does what mine does, no one will ever know.
> But you intercept and you have access to "this".
> Climb up to document, then spider and read the entire web page.
> document.location gives the url he is looking at.
> If it's juicy, gather up information and submit it by form.submit or xhr or whatever.
> 
> Dude - seriously.
> Any sort of interwindow bleed is a security hole.

Yeah...  surprised (and annoyed with my self) that I didn't think about
this...  I guess I just watched the commits land in the repo and didn't look
at the architecture they were creating... sorry about that.

> It came to mind because sm doesn't share pages as easily as duktape.
> I think I figured out how to do it, how to share the master window among all other windows,
> but then I thought: I shouldn't be doing that anyways.
> 
> Ok so building everything in each window is a waste.
> Adam said 8 years ago to write it all in C, and he's sort of right for this reason,
> but rewriting js in c multiplies the code by about 10, no kidding,
> 4500 lines of js becomes 45,000 lines of c,
> all of edbrowse so far after 20 years is about 45,000 lines,
> so we clearly don't have the time or resources for that.
> So we have to settle for where it is.
> But in the grand scheme it's not so bad.
> Web pages pull in jquery, which is ten times as big as my startwindow.js, after minimization, maybe 30 times before,
> and that gets sucked in and processed on every page of the website, and if we're going to handle that,
> then I guess we can build my dom each time too.

Agreed.  Honestly, performance's probably the least of our problems right
now.

> So speak now or forever, but I'm going to restructure it so it builds insitu each time,
> (I like that word, insitu),
> and then the master window, which I'll keep, is only for our third party deminimization software.
> That doesn't even ship with production anyways.

Does that mean it won't be a "master window" without that built? Or are you
going to still have it but ensure isolation in some other way? Or, if
present, will it merely be to hold the extra debugging functions etc?

> So that will keep me up tonight.

I hope it wasn't that bad.

Cheers,
Adam.