You need to
before you can comment on or make changes to this bug.
Add CSP to Frame and add a stub method that checks the response for CSPs
Created an attachment (id=81064) [details]
Adam, not sure this is the right place to add the policy?
(From update of attachment 81064 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=81064&action=review
> +ContentSecurityPolicy::ContentSecurityPolicy(Frame* frame)
> + : m_frame(frame)
The policy should be on the Document because the policy is scoped to a given document. The Frame survives navigation between documents, but the policy doesn't.
> +bool ContentSecurityPolicy::isEnabled() const
> + DEFINE_STATIC_LOCAL(String, CSPHeader, ("X-WebKit-CSP"));
> + Frame* frame = m_frame;
> + if (frame->document()->url() == blankURL())
> + frame = m_frame->tree()->parent();
> + return !frame->loader()->documentLoader()->response().httpHeaderField(CSPHeader).isEmpty();
It looks like you copied this logic from XSSAuditor, but that logic was somewhat specific to that case (especially the blankURL bit). This design won't scale well when we have to do more complex parsing of the policy header. Instead, we should have WebCore call into this object when the header is available, so that it can parse the header once and remember what it said. You can look at how this works for X-Frame-Options.
Attachment 81064 [details] did not build on mac:
Build output: http://queues.webkit.org/results/7693384
@jochen: We should also mark these bugs as blocking the meta bug so folks can follow our progress via the meta bug.
Created an attachment (id=81279) [details]
(From update of attachment 81279 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=81279&action=review
Mostly organizational comments. We want to put as much of the "guts" inside ContentSecurityPolicy as possible. The outside code should be as oblivious as possible.
> +void Document::parseContentSecurityPolicyHeader(const String& header)
> + // FIXME: Actually parse the header.
> + m_contentSecurityPolicy.setEnabled(!header.isEmpty());
parse should be a method on ContentSecurityPolicy. It's the one that's going to do the heavy lifting.
> + void parseContentSecurityPolicyHeader(const String&);
We should just have an accessor for m_contentSecurityPolicy
> + m_frame->loader()->didReceiveContentSecurityPolicyHeader(content);
I'd just change this to call through to the document->contentSecurityPolicy()->didReceiveHeader(content), which can then call parse internally.
Attachment 81279 [details] did not build on mac:
Build output: http://queues.webkit.org/results/7704048
Created an attachment (id=81349) [details]
(From update of attachment 81349 [details])
Created an attachment (id=81350) [details]
Fixing the header attributes so it compiles on mac.
(From update of attachment 81350 [details])
Clearing flags on attachment: 81350
Committed r77742: <http://trac.webkit.org/changeset/77742>
Attachment 81349 [details] did not build on mac:
Build output: http://queues.webkit.org/results/7702330
The commit-queue encountered the following flaky tests while processing attachment 81350 [details]:
http/tests/websocket/tests/handshake-error.html bug 53851 (author: email@example.com)
The commit-queue is continuing to process your patch.