From: Dominique Martinet <firstname.lastname@example.org>
To: Karl Dahlke <email@example.com>
Subject: Re: [Edbrowse-dev] XHR same-domain restriction
Date: Mon, 12 Mar 2018 13:57:22 +0100 [thread overview]
Message-ID: <20180312125722.GA3901@nautica> (raw)
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
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
next prev parent reply other threads:[~2018-03-12 12:56 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
2018-03-12 12:57 ` Dominique Martinet [this message]
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).