Bug 69359 - CSP connect-src directive should block redirects
: CSP connect-src directive should block redirects
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Page Loading
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Nobody
Depends on:
Blocks: 85558
  Show dependency treegraph
Reported: 2011-10-04 11:34 PDT by Sam Weinig
Modified: 2013-03-07 12:52 PST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2011-10-04 11:34:48 PDT
As pointed out by Adam in bug 69353, we should be blocking redirect of XHR, EventSource and WebSockets if there is a connect-src directive.
Comment 1 Sam Weinig 2011-10-04 13:05:20 PDT
Actually, I don't think WebSockets support redirects, but the other two do.
Comment 2 Sam Weinig 2011-10-04 13:09:42 PDT
This is made slightly complicated by the fact that we don't get a chance to stop redirects in the same class that started the load.  I am told this is because we don't want to block an XHR on a worker from making progress, so all policy information has to be on the ThreadableLoader itself. 

One way we could do this is to make ThreadableLoader aware of either the whole ContentSecurityPolicy object (making access to it safe from multiple threads). Another is to just have a way to copy the relevant part of the policy into the loader, and have a mechanism for it provide reports.  There may be other ways, but I am currently leaning toward making the ContentSecurityPolicy thread safe.

Adam, your comments are appreciated.
Comment 3 Adam Barth 2011-10-04 15:35:44 PDT
I would just teach DocumentThreadableLoader about ContentSecurityPolicy.  It might be worth keeping the check you have in XMLHttpRequest.cpp so we can throw an exception in the non-redirect case.  In the redirect case, we can just treat it as a network error.
Comment 4 Adam Barth 2012-05-03 17:33:39 PDT
This isn't likely to be fixed for CSP 1.0.