From: Karl Dahlke <firstname.lastname@example.org>
Subject: [Edbrowse-dev] XHR same-domain restriction
Date: Mon, 12 Mar 2018 08:38:19 -0400 [thread overview]
Message-ID: <email@example.com> (raw)
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
and then the js can access the html via frames.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.
next prev parent reply other threads:[~2018-03-12 12:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 5:09 Kevin Carhart
2018-03-12 6:33 ` Karl Dahlke
2018-03-12 7:17 ` Dominique Martinet
2018-03-12 12:38 ` Karl Dahlke [this message]
2018-03-12 12:57 ` Dominique Martinet
2018-03-14 1:54 ` Kevin Carhart
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).