CSP 1.1: Strip URLs in SecurityPolicyViolationEvents, just as we do for POSTed violation reports.
https://bugs.webkit.org/show_bug.cgi?id=113039

Reviewed by Jochen Eisinger.

Source/WebCore:

I'd originally assumed that we didn't need to be quite so careful when
handing URLs to JavaScript via SecurityPolicyViolationEvents. This was
a mistake. Cross-origin URLs aren't accessible to JavaScript currently
and there's no reason that we should begin exposing them via an event.

This patch extracts the stripping logic from the existing reports into
stripURLForUseInReport(), and uses that new method when populating the
event and report objects.

Relatedly, we were doing the wrong thing with 'file:' URLs, which this
patch made clear. Now they're treated the same as 'data:' et al.

Spec: https://dvcs.w3.org/hg/content-security-policy/rev/45f6ccaba0ef

Tests: http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-cross-origin-image-from-script.html
       http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-cross-origin-image.html
       http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-from-script.html
       http/tests/security/contentSecurityPolicy/report-blocked-file-uri.html

* page/ContentSecurityPolicy.cpp:
(WebCore::stripURLForUseInReport):
    Extract the logic from blockedURI out into a reusable method:
    cross-origin URLs are stripped down to the ASCII serialization of
    their origin, and non-heirarchical (and 'file:') URLs are stripped
    down to the ASCII serialization of their protocol.
(WebCore::gatherSecurityPolicyViolationEventData):
(WebCore::ContentSecurityPolicy::reportViolation):
    Use ::stripURLForUseInReport for blockedURL and sourceFile
    attributes in these two methods.

LayoutTests:

* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-cross-origin-image-expected.txt: Copied from LayoutTests/http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-expected.txt.
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-cross-origin-image-from-script-expected.txt: Copied from LayoutTests/http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-expected.txt.
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-cross-origin-image-from-script.html: Added.
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-cross-origin-image.html: Added.
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-expected.txt:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-from-script-expected.txt: Copied from LayoutTests/http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-expected.txt.
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image-from-script.html: Added.
* http/tests/security/contentSecurityPolicy/1.1/securitypolicyviolation-block-image.html:
* http/tests/security/contentSecurityPolicy/resources/securitypolicyviolation-test.js: Added.
    Updating tests to cover cross-origin scenarios: load cross-origin
    images, and cross-origin scripts that inject images. The former
    should strip the image URL down to the origin, the latter the
    script URL.
* http/tests/security/contentSecurityPolicy/report-blocked-file-uri-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/report-blocked-file-uri.html: Added.
* platform/chromium/http/tests/security/contentSecurityPolicy/report-blocked-file-uri-expected.txt: Added.
* platform/gtk/http/tests/security/contentSecurityPolicy/report-blocked-file-uri-expected.txt: Added.
    This patch changes the behavior of 'file:' URLs to behave similarly
    to 'data:'/'blob:', etc. We weren't previously testing this, now we
    are. We need platform-specific results for Chromium and GTK, since
    those ports have enabled CSP_NEXT, which adds a field to the report.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@146758 268f45cc-cd09-0410-ab3c-d52691b4dbfc