[Edbrowse-dev] XHR same-domain restriction

[Edbrowse-dev] XHR same-domain restriction

[Kevin Carhart]

Speaking of securing the filesystem and following up on Dominique's 
message from a few days ago, do we want to implement the restriction that 
XHR is only allowed to load pages from the domain that you are currently on? 
If so, is this a workable phrasing to make the test?  Assuming an xhr 
object which I am referencing as 'this', this.url is a string.  So I turn 
it into our URL class in order to easily grab and test the host.

if (new URL(this.url).host == window.location.host)
{
allow fetchHTTP to run
} else {
prevent fetchHTTP from running
set this.aborted = true
throw a new error with a message
}

Here's a startwindow that makes this change if we want to do this.
http://carhart.net/~kevin/startwindow_20180311.zip

Tested on the dummy page http://carhart.net/~kevin/badxhr.html

Without the change, xhr.responseText gets the contents of http://pizza.com
With the change, it refuses to load http://pizza.com from carhart.net

[Edbrowse-dev] XHR same-domain restriction

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

I doubt there are restrictions on xhr domains in other browsers. If there were such restrictions, one could get around them easily.

var d = document.createElement("div");
d.innerHTML = "<iframe src=anything-at-all.com></iframe>";
// this fetches the html, just like an xhr request would
d.firstChild.contentDocument.innerHTML;

And I know frames can be inter domain, I see those all the time.

Karl Dahlke

Re: [Edbrowse-dev] XHR same-domain restriction

[Dominique Martinet]

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 = "<iframe src=anything-at-all.com></iframe>";
> // 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 <script>, <frame> etc, and for each of them truncate
attributes like src=... based on some logic...

1; mode=block (what google uses for youtube) will do the same
detections, but instead of just removing unsafe parts will not load the
page at all.

1; report=<reporting-url> will remove unsafe portions and notify some
url, ugh.

 - X-Frame-Options[3], this is semi-unrelated, but can cause a frame to
load or not based on where the <frame> tag came from. Basically have an
option that says frame can only be loaded if the option matches.

For youtube, this is set to 'x-frame-options: SAMEORIGIN' only for the
canonical url and the /embed link does not have it, so I think that is
why the frame does not work.

Interstingly, that means the browser must make the request then decide
to not display/parse the content... This is different from
x-xss-protection that will apply the logic of the base page to decide if
they want to load the js or not.


[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
[2] https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/parser/XSSAuditor.cpp
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options



I'm not sure how that applies to xhr or if it just applies to loading a
js script or not, that's why I didn't post, but might as well send what
I have for now!

-- 
Dominique | Asmadeus

[Edbrowse-dev] XHR same-domain restriction

[Karl Dahlke]

1. Ok, I may be a little bit slow here.
If we restrict xhr, and dynamic frames, that would just slow a trouble maker down, not stop him.
The same guy who writes the js writes the html, so he can put in html
<iframe src=anything.com></iframe>
and then the js can access the html via frames[0].contentDocument.innerHTML
A c program can crank out the html dynamically, and make all sorts of frames.
If you don't want the user to know you're doing it you can set display=none in css so it's not even visible.
That's not as convenient as xhr but it still works.
So I don't see the point.

> 0 will not block anything (what we do right now)

2. The same guy that writes the js, and the html, also sends out the http headers,
so if he wants xhr to access anything then he just sets that http header to 0 and off he goes.
It's like we put a lock on our browser for some kind of security,
but they can open it with an http key, and everybody knows it.
How does that help?

3. If we implement restrictions, we have to do it all,
including the http key that unlocks them, because some website might unlock them
and expect xhr to work on some other domain, and when it doesn't, then the website doesn't work.

4. The matching rules may not be as simple as "same host"
I'm thinking of cookies here.
If you set a cookie on bar.com/a/b, that cookie remains valid for foo.bar.com/a/b,
bar.com/a/b/c, and foo.bar.com/a/b/c.
I'm not sure the details, Chris wrote it, I'd have to go back and read the code.
It seems likely though that xhr restrictions, if they were in force, would be similar.
You could go ahead and fetch foo.bar.com if you were currently on bar.com.

5. I'm not trying to be rude or ungrateful here, I just don't want to do something that makes things worse.
I appreciate all the research you are doing.
As for experimenting with firefox to see what it does, we should do a lot more of that.
I mean that should be our baseline any time we're not sure of how something works.
I've written a lot of css with various side effects, not entirely sure that I'm doing it write.


Karl Dahlke

Re: [Edbrowse-dev] XHR same-domain restriction

[Dominique Martinet]

Hi,

No worry, I agree this isn't easy.
We/you've been working hard to make more sites work so I don't want to
break these either, let's take the time needed to research first.

Adding to that that I'm a little bit paranoid and like to disable as
much as I can get with, but we'll need to come up with a decent
interface to display what's blocked and set exceptions...
I think that'll be the most tricky part here!

Karl Dahlke wrote on Mon, Mar 12, 2018:
> 1. frames

I'm honestly not sure there.
As the website serving the frame you can say you don't want to be
displayed, so that protects the remote point's resources but I think we
really need to check if/how dynamic frames would work and what kind of
other limits there can be.

> 2. The same guy that writes the js, and the html, also sends out the http headers,
> so if he wants xhr to access anything then he just sets that http header to 0 and off he goes.
> It's like we put a lock on our browser for some kind of security,
> but they can open it with an http key, and everybody knows it.

I think the main purpose of this is to protect a website from code
injection.
Say you're a forum or some blog with a comment area. The fields the
users can fill are supposed to be sanitized, but often enough someone
comes up with a way to insert actual html code/js and could hijack the
user's sessions or whatever it is they want to do.

http headers are usually set by the web server directly without regards
for the content, so no matter how much the site is defaced if the site
says don't load external stuff then it won't load them.

The disabled mode must have been added for compatibility.
Ultimately, if some site depends on it by design and they haven't taken
the time to say code.jquery.com is allowed then they can just set 0 and
things will keep working even if they don't protect themselves.

> 3. If we implement restrictions, we have to do it all,
> including the http key that unlocks them, because some website might unlock them
> and expect xhr to work on some other domain, and when it doesn't, then
> the website doesn't work.

Definitely agreed there, both headers I pointed at have a disabled mode
and it should be easy to implement as it is what we currently do -
basically we just have to make the checks conditional.


> 4. bar.com -> foo.bar.com

That's likely true, need to check as well.

-- 
Dominique | Asmadeus

Re: [Edbrowse-dev] XHR same-domain restriction

[Kevin Carhart]

I'm interested in the discussion that followed here.  I don't have a 
problem with not simply wrapping the fetchHTTP call.  It might be a good 
idea to address this somehow, but I take Karl's point that circumvention 
is only one 'make' away assuming someone knows what make is.
What Dominique is saying about preventing code injection attacks is also 
important. I think part of the problem is that we are simultaneously a little like 
firefox/chrome/IE and a little like wget/curl, or for that matter, like 
'rm' the C program.  The author of rm doesn't write rm and then try to protect 
you from it, do they?  I don't know.  Do we have a savvy audience 
who can worry about their own caution, or a mass audience who we ought to 
protect from bricking their routers??

> I doubt there are restrictions on xhr domains in other browsers.
> If there were such restrictions, one could get around them easily.

I am not saying this hasn't been superceded later on by workarounds, but 
it's part of bedrock, early AJAX information that there is a restriction 
on the domain, or is supposed to be.  W3schools has a lot of outdated 
pages and is occasionally ridiculed (there was a site called w3fools 
advising not to use it), but here is their basic AJAX 
information which I probably "grew up with", or used as a reference in 
2007 or 2010: "...For security reasons, modern browsers do not allow 
access across domains.  This means that both the web page and the XML file 
it tries to load, must be located on the same server.  The examples on 
W3Schools all open XML files located on the W3Schools domain..."

So when I reference it as though it's a fact of life, that's where I'm 
getting it from.  After that it bifurcates into what kind of audience 
you're talking about and what is at stake.