[ServiceWorker] CSP support for ServiceWorker environment.

Source/modules/serviceworkers/FetchManager.cpp

Index: Source/modules/serviceworkers/FetchManager.cpp
diff --git a/Source/modules/serviceworkers/FetchManager.cpp b/Source/modules/serviceworkers/FetchManager.cpp
index 60d36c97f7501562cdd2aad5c4d613fce7b9263d..006264d615b5b07a437af41be6e894bb14ecf6a5 100644
--- a/Source/modules/serviceworkers/FetchManager.cpp
+++ b/Source/modules/serviceworkers/FetchManager.cpp
@@ -12,6 +12,7 @@
 #include "core/dom/ExceptionCode.h"
 #include "core/fetch/FetchUtils.h"
 #include "core/fileapi/Blob.h"
+#include "core/frame/csp/ContentSecurityPolicy.h"
 #include "core/loader/ThreadableLoader.h"
 #include "core/loader/ThreadableLoaderClient.h"
 #include "modules/serviceworkers/FetchRequestData.h"
@@ -157,11 +158,16 @@ void FetchManager::Loader::start()
     // "4. Let response be the value corresponding to the first matching
     // statement:"
 
-    // "- should fetching |request| be blocked as mixed content returns blocked
-    //  - should fetching |request| be blocked as content security returns
-    //    blocked
-    //      A network error."
-    // We do mixed content checking and CSP checking in ResourceFetcher.
+    // "- should fetching |request| be blocked as mixed content returns blocked"
+    // We do mixed content checking in ResourceFetcher.
+
+    // "- should fetching |request| be blocked as content security returns
+    //    blocked"
+    if (!ContentSecurityPolicy::shouldBypassMainWorld(m_executionContext) && !m_executionContext->contentSecurityPolicy()->allowConnectToSource(m_request->url())) {

[Mike West, 2014/11/19 10:31:49]

Why do we do the CSP check here, rather than in ResourceFetcher? It would be
nice to centralize the security checks we're applying to resource requests.

[horo, 2014/11/19 12:35:41]

The old comment was wrong.
We don't check CSP for fetch API currently.

The CSP check for "connect-src" is not handled in ResourceFetcher but in
XMLHttpRequest::open() and NavigatorBeacon::canSendBeacon() and
DOMWebSocket::connect().
So for fetch API it is better to check this in FetchManager::Loader.

[Mike West, 2014/11/19 12:40:45]

We check in both XMLHTTPRequest and ResourceFetcher, don't we? ResourceFetcher
catches redirects, which aren't visible from `open()`.

[horo, 2014/11/19 12:57:34]

Are you saying "both XMLHTTPRequest and DocumentThreadableLoader"?
Yes.
DocumentThreadableLoader::isAllowedByContentSecurityPolicy() is called to check
the redirected URL.

+        // "A network error."
+        performNetworkError();
+        return;
+    }
 
     // "- |request|'s url's origin is |request|'s origin and the |CORS flag| is
     //    unset"
@@ -311,6 +317,7 @@ void FetchManager::Loader::performHTTPFetch()
     }
 
     ThreadableLoaderOptions threadableLoaderOptions;
+    threadableLoaderOptions.contentSecurityPolicyEnforcement = ContentSecurityPolicy::shouldBypassMainWorld(m_executionContext) ? DoNotEnforceContentSecurityPolicy : EnforceConnectSrcDirective;
     if (m_corsPreflightFlag)
         threadableLoaderOptions.preflightPolicy = ForcePreflight;
     if (m_corsFlag)
@@ -318,7 +325,6 @@ void FetchManager::Loader::performHTTPFetch()
     else
         threadableLoaderOptions.crossOriginRequestPolicy = AllowCrossOriginRequests;
 
-
     m_loader = ThreadableLoader::create(*m_executionContext, this, request, threadableLoaderOptions, resourceLoaderOptions);
 }