From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Permerror (mailfrom) identity=mailfrom; client-ip=2001:41d0:1:7a93::1; helo=nautica.notk.org; envelope-from=asmadeus@notk.org; receiver= Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 9090577893 for ; Mon, 12 Mar 2018 00:16:12 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 1001) id 9E48FC009; Mon, 12 Mar 2018 08:17:47 +0100 (CET) Date: Mon, 12 Mar 2018 08:17:32 +0100 From: Dominique Martinet To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20180312071732.GA14308@nautica> References: <20180212023318.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180212023318.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Edbrowse-dev] XHR same-domain restriction 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, 12 Mar 2018 07:16:13 -0000 Karl Dahlke wrote on Mon, Mar 12, 2018: > I doubt there are restrictions on xhr domains in other browsers. If > there were such restrictions, one could get around them easily. Hm, I don't know how it works, but firefox did not do any network request to pizza.com when loading Kevin's page. > var d = document.createElement("div"); > d.innerHTML = ""; > // this fetches the html, just like an xhr request would > d.firstChild.contentDocument.innerHTML; That's intersting. I tried that as well and it refused too, this time I could follow a bit better, it looks like the frame is not loaded without some extra function call and contentDocument is null. Maybe it'd work if the iframe is loaded in the original html though, don't have the time to test right now. > And I know frames can be inter domain, I see those all the time. There actually are rules for that with content security policy. For example, with most browsers you cannot make an iframe with the normal youtube url directly (https://youtube.com/watch?v=something will not load), but the "embed" url https://youtube.com/embed/something does work. I'll post now what I wrote over half a year ago, this is not finished and I do not expect us to do all this yet, but there are at least two more http headers that matter for xhr and js: - X-XSS-Protection[1], which can take a few different values: 0 will not block anything (what we do right now) 1 (browser default) will attempt to remove "unsafe parts" of javascript. The logic is not precisely described anywhere I could see, but I guess code holds the truth, and a few sites linked directly to webkit's XSSAuditor.cpp[2] file. I have not read it completely yet, but it looks like it will go over all the tags in