Re: CSP and cross-frame communication

Le 05/03/2012 20:13, Daniel Veditz a écrit :
> On 3/1/12 1:10 AM, David Bruant wrote:
>> This limitation of "2 levels of trust" is exactly what got us
>> screwed in web security in the first place. The "if you trust, it
>> can do anything you can do" case is what allows XSS to be successful.
> Most XSS comes from programming mistakes in trusted content.
I agree.

> Dividing trust into finer levels doesn't really help with that problem.
It has severely help mitigating a bunch of XSS. By design, the local
storage API does not allow access to all the browser storage. That's a
way of divinding trust (granularity is questionable) and that helped
with mitigating the effect of XSS.
Likewise, the geolocalisation API allows the user to decide whether or
not a page is allowed to access her location. This is another way to
divide finer levels of trust and certainly preserve the privacy of XSS
victims.

A tremendous number of design decisions have been made to define finer
levels of trust and it does help mitigate the effect an XSS can have.

>> As an example, the different combinations of the script-src
>> directive are as many different levels of trust. You load a document
>> and decide to trust:
>> 1) no script at all
>> 2) some scripts sources (list declared in the directive)
>> 3) some scripts sources without unsafe evals
>> 4) no inline scripts
> There are still only two levels -- sources you trust completely and
> sources you don't. And if you allow inline-script and eval() you
> probably aren't preventing any XSS attacks because the
> attacker-injected content is indistinguishable from a source you trust.
I agree for inline script, because the problem that comes with them
comes from their execution model (they execute without asking permission
to anyone and no script already in place can prevent the execution of a
later-inserted script).

I strongly disagree regarding eval. When I use eval in my own code, I
have the possibility to check the input beforehand regardless of where
it's from (luxury I don't have with inline scripts). I can't think why
preventing people from using eval helps them in any way from a security
perspective.
Projects like Caja [1] use eval [2][3] and I wish you good luck to
exploit it.

Do you have an example of an XSS that can be avoided by the specific
prevention of eval? I'm obviously talking about a case where eval is
legitimate.
People who misuse eval will at best not be aware of CSP and at worst say
"it broke my code" and disable it right away when trying it.

> Getting from where the ad hoc creation of the web has left us to a
> safer future isn't going to be easy.
I could not agree more :-)

> CSP's baby steps toward forcing
> authors to separate script and content are only a start.
Interesting. What are the next steps? Can you tell more? Or where can I
read more about the long term vision of the web platform security?

David

[1] http://code.google.com/p/google-caja/
[2]
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#634
[3]
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#574

Received on Monday, 5 March 2012 19:59:20 UTC