From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (mailfrom) identity=mailfrom; client-ip=8.23.224.60; helo=out.smtp-auth.no-ip.com; envelope-from=kevin@carhart.net; receiver= Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 5197D77A9A for ; Mon, 5 Mar 2018 15:33:56 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id 35AA02FF for ; Mon, 5 Mar 2018 15:35:20 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id w25NZJ8q015108 for ; Mon, 5 Mar 2018 15:35:19 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id w25NZIZQ015104 for ; Mon, 5 Mar 2018 15:35:19 -0800 Date: Mon, 5 Mar 2018 15:35:18 -0800 (PST) From: Kevin Carhart To: Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20180305223246.GA20658@nautica> Message-ID: References: <20180205171750.eklhad@comcast.net> <20180305223246.GA20658@nautica> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Edbrowse-dev] zip and security X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.25 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 23:33:57 -0000 On Mon, 5 Mar 2018, Dominique Martinet wrote: > Karl Dahlke wrote on Mon, Mar 05, 2018: >> He writes a web page with javascript that does an xhr request to >> zipxd://foo.zip@:@top > > I think it's a matter of priority, but now we have javascript working a > bit better we might soon find time to make it more restricted somehow. > > I still think allowing any site to do xhr requests anywhere is not > something we will want. I completely agree. For a long time we've been in a pocket. It didn't matter that much because we didn't have a lot of pages that were getting all the way through the several steps of retrieving responseText, going to a callback, processing the content, and innerHTML side effects take it back to EBML. (!) It's very exciting that we started to get this, so congratulations, our prize for breaking through is a new tier of robust worries.. I could write the same-origin restriction into javascript. Not that this covers it entirely, but at least the default would be strict and we would block some opportunists. Suppose I have just loaded abc.com, and I instantiate a new XHRHttpRequest object. I try to retrieve a page from def.com. Should I intercept this in javascript before it gets to fetchHTTP, and fail silently? Or throw something? > I started writing a mail about this ages ago (August last year!) and it