CSP should correctly block plugin resources rendered in PluginDocuments.
https://bugs.webkit.org/show_bug.cgi?id=92675
Patch by Mike West <mkwst@chromium.org> on 2012-08-01
Reviewed by Adam Barth.
Source/WebCore:
In certain cases, plugins aren't loaded directly, but are stuffed into a
newly-created PluginDocument before rendering. While we were already
correctly populating information that allowed us to make decisions about
that document's security origin, and already dealing with sandbox
status by creating a 'SinkDocument' that ignored plugin data, we weren't
correctly inheriting the parent frame's Content Security Policy. This
patch ensures that PluginDocuments correctly inherit their parent's
Content Security Policy, meaning that the plugin is blocked or allowed
according to the policy of the protected resource in which the
PluginDocument is embedded.
Tests: http/tests/security/contentSecurityPolicy/object-src-url-allowed.html
http/tests/security/contentSecurityPolicy/object-src-url-blocked.html
* dom/Document.cpp:
(WebCore::Document::initContentSecurityPolicy):
Populate a created PluginDocument with its frame's parent's Content
Security Policy.
LayoutTests:
* http/tests/plugins/resources/mock-plugin.pl: Added.
This lovely perl script mocks a plugin by sending a
'Content-Type application/x-webkit-test-netscape' header.
* http/tests/security/contentSecurityPolicy/object-src-url-allowed-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/object-src-url-allowed.html: Added.
* http/tests/security/contentSecurityPolicy/object-src-url-blocked-expected.txt: Added.
* http/tests/security/contentSecurityPolicy/object-src-url-blocked.html: Added.
Test that non-'data:' URLs that end up in PluginDocuments are also
dealt with correctly by CSP.
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124371 268f45cc-cd09-0410-ab3c-d52691b4dbfc
8 files changed
