Le 02/02/2012 00:02, John J Barton a écrit :
On Wed, Feb 1, 2012 at 2:41 PM, David Bruant<[email protected]> wrote:
Hi,
I have claimed here a couple of times, that in a JavaScript application
containing code from different parties, the first to run is the one that
is in position to make decisions about security of the overall
application (freezing the primordials for a defender or monkey-patching
them if you're an attacker). I still have no proof (I feel it's coming
though) about it, but a strong intuition.
Assuming this is true, then, on the web, one has to make sure that her
protecting script runs first. How to ensure this, though? There is
always a risk that with an XSS an attacker scripts runs before the
protecting one.
I think I have found an answer and it is: with Content Security Policy
(CSP) [1].
Perhaps you can help me understand your reasoning here. To me, you
have indeed "found the answer" and the "one that is in position to
make decisions about security of the overall application" is in fact
the browser the implements CSP.
The context I'm placing myself in is the one of a web application
author. As such, I rely on the web browser to ensure some security
properties (tab isolation, standard compliance, for instance)... as well
as the browser relies on the operating system to ensure some security
properties (process isolation, for instance)... as well as the operating
system relies on the hardware... Somewhere, there is also the network
and a hope that there is no DNS spoofing in the network the browser is
running
Before CSP, some "security-impacting" properties that the browser was
providing when it came to script execution were :
- scripts can be loaded from anywhere
- there are inline scripts which execution can't be prevented
In before-CSP platforms, as a web author, my trusted script is no more
powerful than any other (potentially untrusted) script. This
non-distinctive situation is what led to XSS being possible.
Within a CSP-enabled platform, as a web author, I can decide that only
some scripts are granted full authority and based on that reduce the
authority of additional scripts.
The browser does not make decisions about the security of my
application, it only provides some security properties I can rely on to
ensure the security of my application.
And the security properties that CSP-enabled browsers provide are a
game-changer.
I guess you have some use case in mind that you might share. It seems
to me if you don't want a script to load, then don't load it.
But somehow you want to load this attacker then prevent it from being
successful?
Things are not that easy. Trust can be partial sometimes. In some cases,
the "attacker" is an ad provider. You want it to be able to display the
ad (because you need money to pay for food), but not allow the ad script
to mess with the rest of your page (because there might be other ads
providers in the same page and they give you money too!).
Another example: I heard that MDN wishes people to be able to send their
applications so they can test web technologies quickly (very much like
W3Schools's tryit [1]). This is possible securely without iframes within
a CSP-enabled browser.
What I want is to load a potentially untrusted script and grant it the
authority to do its job and nothing more. In some places, they call this
"applying POLA" (Principle Of Least Authority), because you provide to
some script the least authority it needs to do its job.
David
[1] http://www.w3schools.com/js/tryit.asp?filename=tryjs_events
[2] http://en.wikipedia.org/wiki/Principle_of_least_privilege
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
