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

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 referencing 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.

[1]: http://www.youtube.com/watch?feature=player_detailpage&v=YDW7kobM6Ik#t=1749s