From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26906 invoked from network); 15 Nov 2020 12:27:08 -0000 Received: from hurricane.the-brannons.com (2605:2700:0:17:a800:ff:fe3e:bc77) by inbox.vuxu.org with ESMTPUTF8; 15 Nov 2020 12:27:08 -0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by hurricane.the-brannons.com (Postfix) with ESMTP id 123FE21DE05 for ; Sun, 15 Nov 2020 04:27:03 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by hurricane.the-brannons.com (Postfix) with ESMTPS id EEC4077AF7 for ; Sun, 15 Nov 2020 04:27:02 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id p8so15670158wrx.5 for ; Sun, 15 Nov 2020 04:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WJKv5PDYWcJA/lJLD0mGOeDIXk7BSbhci9bNbagDkPg=; b=aJIKkBwD6/PtnNkIXf2i+W/feP4hrlJ0cA4tAiTOE6E9sJ5mVHpKnc+PNdEizYxchS 9LufWxCQwC5oxX8HnZ3s1JuC35BKbM3k0M+ZI0F8yq4X/njWD6sxN0t59FaqVZbsFEb9 VkVrgcNufGXqQtoBVI1S9lLZbDznBl6+9Bv5Wntx8WZaUSNjfgwHejkyJQ06uQcwz76I r+UqKcWyVmxMTHim/6FPKeR1E8nSaOQ38V2f68pMVvdX9xdDdoJQoqewa68wpp2r5XWr kcdPy4mLOcST5jWSt7rWroScV8vKI+qsG0hGqBGRLwSKpu6hu7Qqi2YYs8XCBYDZLa60 M0Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WJKv5PDYWcJA/lJLD0mGOeDIXk7BSbhci9bNbagDkPg=; b=oATmUbMMpzRL1OLAc3ca206exu6Kr4fhMm2ZuuCKHSeeH3dkRQb7iQXL+9OcH/9NDA A+NldhGqDq2FedVS//GZN3s3LfcxTfz2twURN8bDKjIDUTt0AkekodEVtrBNKjFbJLk+ SEhFvPN3GpD4j/dcNG8AIjgcGvlEG2pJFsAl9C1HGiwX3kpTP2Mm21pGswGdUjPgWjYW lzy77qJsUe77kqu2vMOqHYbOpgEFPqUeth2BhnTPriPIK4AFRjdDqGlsCUVCsyOXIaBZ 499NAjla/eMDHN5l9v2OUnqYBzWPa3hJ+IVZZo5/wz3NAjVh8TsQlgHBtmdHNUwcUJwB cZxg== X-Gm-Message-State: AOAM531X/eVZ3hxFpWfKl9JKXAsCYDXP6dGZJbMazzu9QeAOVRqHix4g qutcfkiJJKntYDGifeEGWvI= X-Google-Smtp-Source: ABdhPJyYQ0U+4VuuecUGU4wXq9QQ+joJNUVslQnh+I0GR0c/c7fBDZxWVn3Pyk75pL1z96A05rPIOQ== X-Received: by 2002:adf:e6c8:: with SMTP id y8mr13856828wrm.414.1605443220821; Sun, 15 Nov 2020 04:27:00 -0800 (PST) Received: from toaster (b.5.b.9.4.f.e.f.f.f.c.f.1.b.a.e.1.4.0.9.2.4.1.1.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:1142:9041:eab1:fcff:fef4:9b5b]) by smtp.gmail.com with ESMTPSA id k16sm19126098wrl.65.2020.11.15.04.26.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 04:26:59 -0800 (PST) Date: Sun, 15 Nov 2020 12:26:57 +0000 From: Adam Thompson To: Karl Dahlke Cc: edbrowse-dev@edbrowse.org Subject: Re: [edbrowse-dev] interwindow bleed Message-ID: <20201115122657.GA10863@toaster> References: <20201005232257.eklhad@comcast.net> <20201109231116.GB4369@toaster> <20201009202834.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201009202834.eklhad@comcast.net> 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.