How to ensure that your script runs first in a webpage

David Bruant bruant.d at gmail.com
Thu Feb 2 00:51:04 PST 2012


Le 02/02/2012 00:02, John J Barton a écrit :
> On Wed, Feb 1, 2012 at 2:41 PM, David Bruant<bruant.d at gmail.com>  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


More information about the es-discuss mailing list