Le 09/04/2013 18:48, Bjoern Hoehrmann a écrit :
* David Bruant wrote:
Opinions differ. Some would say the Same Origin Policy is a legacy
compatibility issue. I'm of that side. It's pretty annoying that a
server-side opt-in is required for sharing. It would be lovely if
sharing on the web was as simple as sharing a URL [1]. It very often
isn't (cookies, CORS as an opt-in).
Just to be clear, the traditional problem is that browser cannot know if
any given resource is "on the web" or some kind of "intranet" resource,
and allowing arbitrary web pages to access intranet resources is bad.
I agree. Notice that holes in the Same Origin Policy allow to gather
information anyway; sometimes enough to enable an attack to find
someone's location to ~30 feet accuracy [1]. And these holes can't be
fixed per spec.
The talk I linked to is just another proof of that that the browser
fails in its mission to enforce a strict Same-Origin Policy (and that
can't be fixed)
I believe it actually shouldn't be the browser mission. I believe it
should be human beings role to organize their URLs so that they're just
plain unguessable to any malicious website trying to scan your local
network when the resource they locate is precious.
Interestingly, if you start making your URLs unguessable to attackers,
you start to realize you don't need browsers to enforce the Same Origin
Policy anymore, but that's a different topic.
Although the browser provides some mitigation by enforcing the
Same-Origin Policy, it isn't clear what prevents an iOS or Android app
to scan a local network (because I don't believe apps have to enforce
the Same Origin Policy as the web does).
For sure, if you local network have unguessable URLs, you're protected
from network-scanning phones. (I heard that in some big
companies/military places, people who do not work for the organization
are asked to leave their phone at the entrance...)
Anyway, the web have survived until 2013 to cross-domain scripts; I
don't think modules add security issues, so I don't see a reason module
imports should act differently than <script>. Especially given how easy
it is to confine a module.
A constraint with <script> is that you cannot actually read the source
text that the browser evaluates, accordingly people would use "JSON-P",
JSON wrapped inside a function call, to read JSON data, rather than re-
ferencing the content directly via <script>.
JSON-P is a pre-CORS technique that should probably be forgotten. If a
third-party accepts to share data in a cross-domain fashion, they can
make the data available and add the CORS headers. iframe+postMessage can
work too. I imagine there is a way to make cross-domain Server-Sent
Events and WebSockets work too (I have never tried)
There are legitimate ways to share data across domains without the
<script>-abusing JSON-P technique.
The devil here is usually
in the details, https://bugzilla.mozilla.org/show_bug.cgi?id=485645 is
an example.
This has been fixed both in the ES5 spec and implementations, but I see
what you mean.
David
[1]
http://www.youtube.com/watch?feature=player_detailpage&v=YDW7kobM6Ik#t=1749s
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
