Re: More on XSS mitigation (was Re: XSS mitigation in browsers)

(slowly getting through the mass of mails)

Michal Zalweski:
> They are accessible programmatically in all the approaches proposed;
> the difference is that in CSP, they are accessible on server-side, and
> in Adam's proposal, on client side.

I meant to say 'client-side programmatically accessible'
As pointed out earlier ; with Adam's proposal CSP like behavior can be
achieved by a simple XHR. But you can also use a XDomainRequest(or
CORS) to send the report to another domain, and the developer has the
flexibility to remove any details he doesn't want to send. Tomorrow, I
can imagine someone writing an app that is just a simple static HTTP
server on the server side, and all the magic is in the JS code. Seems
that in this case, you would have to setup something on your domain
for server side code (for ,say ,DOM based XSS), which seems like an
avoidable burden to me.

Michal Zalewski wrote:
> not cause insurmountable security problems, does not reduce the
> effectiveness of the mechanism in most uses, and does not introduce
> excess complexity in single-policy-spec cases.

I think support for meta + HTTP headers (arbitrary number of them)
that intersect to the most restrictive setting is good.
Its effective and simple for the single policy-spec (its no different
than any other proposal for single-policy spec case).

Michal Zalewski wrote

> 1) Allowing policies to be defined in HTTP headers; and then parse
> first relevant <meta> if no HTTP header policy is found. There is a

I can't understand why you only want to restrict to the first meta
tag, and stick to the either/or for headers and meta tags. HTTP
Headers AND META tags in the <head> can both be used I feel.

> 2) Allowing policy violations to be reported to server-side callbacks
> (which offers improved detection rates for gross policy specification
> errors - in your proposals, these would not get reported if the
> handler itself fails to load); and DOM handling of policy violations

In the little while I played with CSP, Gross policy specification
errors occurred when I was first trying to write the policy. In that
case, it was *much* easier to just look at the console and the output
instead of looking
at weird JSON (or was it XML?) data at the server side (as well as
having to write a server side handler that outputted it to a console
that I had access to etc etc). I would bet money that the use case you
are talking about
is better handled by echoing violations on the error console. Thats
how developers (at least me:) do bug fixing -- open up Firebug or the
Chrome console.

> 3) Allowing inline scripts guarded by policy-specified nonce tokens
> (<meta> says "inline-script-token=$random", inline scripts have
> <script token="$previously_specified_random">...</script>). This
> eliminates one of the most significant issues with deploying CSP or
> this proposal on sites that are extremely concerned about the overhead
> of extra HTTP requests; for example, much of * is subject
> to such concerns.

I am not sure this should be a target for the first revision.

> 4) Having a policy flag to choose between origin-based specifications
> (which are more convenient, but problematic for two reasons: the JS
> API problem outlined earlier, and the out-of-order / out-of-context
> loads described in the mail below) and explicit URL whitelisting (more
> verbose and harder to maintain, but significantly safer from that
> perspective).

Your SOP/browsersec foo is *much* higher than mine, so this is all
imho. I am worried about having conflicting policies --- everything
else is about origins while this is about URLs; this conflict is just
confusing to me. Also, this reminds me of the cookie mess. But I
imagine you have thought of these issues.


Received on Saturday, 22 January 2011 02:30:37 UTC