Re: XSS mitigation in browsers

Hi

Sorry to nitpick --- but I would *really* appreciate it if the
clickjacking (or UI hacking) stuff is moved to a new thread. This
thread is titled 'XSS mitigation in browser' :)

Sorry for the long post; I am specifically replying to points Michal,
Brandon and Adam raised (in that order below)

Michal Zalewski wrote:
> 1) Implementators should probably be strongly advised that the first
> allowed-scripts value must take precedence; even if this is otherwise
> mandated by HTML5, the mechanism may be backported to
> non-fully-compliant renderers, so it would be good to emphasize this.

IMO, CSP's solution of only making the policy more restrictive is a
better solution than saying 'first must take precedence'.

Michal Zalweski wrote:
> I think we're splitting hairs here. Both approaches could be safely
> combined by allowing HTTP headers to specify policy, in which case
> meta is ignored (which rules out injection woes completely); or meta
> to be interpreted if HTTP header is not present (in cases where site
> owner can't manipulate server settings). But either way, with minimal
> diligence and properly defined parsing rules, the risk in both cases
> is pretty low.

How about instead allowing the meta tag policy to only make the policy
more restrictive than the one defined in HTTP headers? (following my
previous suggestion).

Michal Zalewski wrote:
> Request: GET /some_public_js_api?callback=foo
> Response: foo('some_public_data')

> These will have valid Content-Type values, but by specifying evil
> callbacks, can be subverted likewise - just inject:

I am hoping (praying?) that this JSON-P crap goes away after we have
CORS or XDomainRequest.

And anyways, it seems that in this case what will happen is that a
developer controlled (non-malicious) function
will be executed with malicious arguments. While bad, I think it
shouldn't qualify as 'injection'. Maybe I am missing
something?


Brandon Sterne wrote:
> Can you explain the motivation for this change?  If sites want to be
> informed of the violations as they occur, won't they set up an event
> handler which sends XHRs back to the server anyway?

It seems to be that this is exactly a good motivation for this. This
makes this proposal simpler and cleaner, and if the developer wants to
be notified on SMS in addition to a log to his site, he can do that
too. Or he can change his last.fm to play songs of doom. But the point
is the developer should have a programmatic choice of doing what he
wants -- over the current CSP proposal. The CSP proposal currently
gets unnecessary cruft like 'should we add the cookies? Whats should
be the format of the report document? Should we send it if report-uri
is cross origin? What if there are multiple report-uris?' All these
look unnecessary to me.


To me it looks like Adam's proposal makes 2 key new ideas:

* It should be possible to specify policy without messing around in
headers. With the 'extra policy can only make things more restrictive'
setup, I don't see why this isn't a good idea.

* It should be possible to handle violations programmatically. As I
argued before, I think this is a cleaner/simpler/better/flexible
design than the current CSP design. As Adam noted before, the
SecurityViolation (and whatever its called in CSP) is for programmer
convenience and thus accessing it programmatically (which is imho more
convenient for the developer) is a good idea.


thanks
devdatta

Received on Friday, 21 January 2011 21:48:48 UTC