Image example

Deleted: gplay-false.png 17.9 KB

	gplay-false.png 17.9 KB View Download

Yes, the use of the XSS Auditor to "snipe" script in a victim page is a known attack, described here: https://www.chromium.org/developers/design-documents/xss-auditor

To mitigate the threat of sniping, the filter now blocks the load of pages by default instead of simply neutering the selected script element.

Would it be a good idea to add a CSP directive, say "auditior-whitelist: cdn.example.com"; for which src scripts that are located on specified sub-domain do not trigger the auditor?

This would give developers more control, rather than just an outright page block? I believe certain sites revert to X-XSS-Protection: 0; due to "sniping" which IMO isn't the best solution for them.

Just a suggestion I had, any thoughts?

A site with a strong CSP is in a good position to safely disable the XSSAuditor as the declarative power of CSP makes it easy to forbid unsafe inline script and to gate what sources of remote scripts are permitted.

I'm not sure that it would be worthwhile to add new directives to CSP to attempt to mitigate this further, as they seem unlikely to be broadly used. Attempting to automatically exempt scripts that match any existing CSP script-src rules might be more effective but I think the return-on-investment would probably still be quite low. 

Interesting suggestion.  I agree that we do not want any new directives, but we might well consider giving a pass to scripts for which the developer has provided an explicit CSP script-src directive (or object, for object-src, etc.)

Mike, thoughts?

Actually adding mkwst this time.

Alternatively, maybe the presence of a given directive should turn the auditor off for that class of token (and save some cycles).

I don't think it's a good idea to add new directives to CSP in order to manipulate the state of the auditor. I could imagine disabling the auditor in the presence of nonces/hashes (though there's still some marginal risk with the former that the URL could be reflected into an existing script block).

*shrug* I don't have a strong opinion about this. Honestly, now that we're blocking by default, I was hoping that we'd just get rid of the "filter" mode entirely rather than add more complexity on top of it.

WDYT, Tom?

I'm not worried about the filter mode; rather whether this would drop the false positive rate while blocking, given that sufficient CSP makes the auditor redundant.

In the end, I don't think we'll want to move forward on this.