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

[Dominique Martinet <asmadeus@codewreck.org>]

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