Re: [edbrowse-dev] interwindow bleed

[Adam Thompson <arthompson1990@gmail.com>]

On Mon, Nov 09, 2020 at 08:28:34PM -0500, Karl Dahlke wrote:
> > surprised (and annoyed with my self) that I didn't think about this...
> 
> Yeah, me too. Ha ha.
> It's a funny thing about security. If you're not thinking about it, you're really not thinking about it. Then when you do think about it, sometimes it only takes 5 minutes of thought to see the problems.
> Like turning a light on.
> It just came to me in the shower.

Indeed.  Given that I used to work for a cybersecurity company (all be it on the
web proxy component) I should've been more alert to this I think.

> > Does that mean it won't be a "master window" without that built?
> 
> As of 3.7.7, and in production, it's just an empty object, unless you build the way I do,
> with EBDEMIN=1, then all our tracing and debugging and deminimization stuff goes in there.

sorry if this reflects a lack of knowledge but does the presence of this
global object still open an, admittedly potentially contrived and
Edbrowse-specific, path to break the new isolation?

> > I hope it wasn't that bad.
> 
> Oh I didn't mean it in a bad way. I have chronic insomnia, or more accurately, non24,
> so if I have something interesting to work on at night, that's good.
> It was a pretty easy change, actually, to build all our stuff in each window, rather than once in the master window.

I'm glad that it wasn't too difficult to fix.

> It didn't take long to do that, and now windows are properly isolated, well, except for frames, and that's as it should be.
> I've seen more and more sites use code like this:
> 
> if(top != window) { stop and don't do anything }
> 
> This guards against a security attack where your juicy site is pulled in as a frame of a larger site,
> maybe the frame is your bank, and you log in, and the larger site that owns this frame can dip in and see your login and password.
> Well, top is the top window that has all the frames,
> and not the current window, which is your bank,
> so that simple test comparing top and window guards against interwindow bleed
> through the frame system.

One of my friends has just rewritten a bunch of html docs which did creative
things with frames.  This is apparently because some browsers are now
isolating frames (i.e.  the above guard) without requiring sites to do this.
I've no other reference for this currently but it was a rather substantial
rewrite and thus I suspect it was indeed required.

> Even if we can stay with duktape, which would be nice, I'm learning alot by this project, c++ for example, now have a better feel for it,
> and the nuts and bolts of the spider monkey api.
> I've already confirmed it is up to date, and handles all the things that duktape doesn't.
> And it led me to the security hole, so it's all good.

Indeed.  Often it pays to revisit code like this.

> It would be really great if we could build either or both at will in the ongoing future,
> but I don't think we can.
> The changes would spread outside of jseng_whatever.c and into three or four other C, perhaps having to become c++, files.
> I'm losing some of my encapsulation.

Indeed.  As I said it's a real shame if duktape isn't keeping up.

As a question, what is the promise stuff they're lacking? It looked like
they implemented this but I really don't know js enough to have an opinion.
I also wonder whether we need to embed duktape (which I know I've previously
spoken against) so that we can potentially enable anything which is switched
off in the default build.  It looks like, if this genuinely buys us any
features, it'd just be a .c and .h file to pull in.

Just food for thought.

Cheers,
Adam.