[webcrypto] Only allow crypto.subtle.* to be used from "secure origins".

Source/platform/weborigin/SecurityOrigin.cpp

Index: Source/platform/weborigin/SecurityOrigin.cpp
diff --git a/Source/platform/weborigin/SecurityOrigin.cpp b/Source/platform/weborigin/SecurityOrigin.cpp
index 652560af325dcf8ba1f0ae4a4f97b609654b7ef5..c4afa5bc5e075159bcec0f7ed9ee16a10ec5fa5a 100644
--- a/Source/platform/weborigin/SecurityOrigin.cpp
+++ b/Source/platform/weborigin/SecurityOrigin.cpp
@@ -375,6 +375,93 @@ bool SecurityOrigin::canDisplay(const KURL& url) const
     return true;
 }
 
+// This implementation follows:
+// http://www.chromium.org/Home/chromium-security/security-faq#TOC-Which-origins-are-secure-
+//
+// See the unit-tests in SecurityOriginTests for specific examples.
+//
+// There are some subtleties in what the SecurityOrigin ends up being for
+// various circumstances, especially scripts involving data:URLs:
+//
+// FIXME: http://crbug.com/362214: Codify these as tests, rather than documentation!
+//
+// Source a <script src="data:..."> from within a https://secure document
+//   * The script should be granted access
+//   * The script's SecurityOrigin inherits from the parent document, and will
+//     be https://secure.
+//
+// Source a <script src="data:..."> from within a http://evil document
+//   * The script should NOT be granted access.
+//   * The script's SecurityOrigin inherits from the parent document, and will
+//     be http://evil.
+//
+// Source a <script src="http://evil/foo.js"> but the server redirects to a data:URL
+//   * The script should NOT be granted access.
+//   * The script's SecurityOrigin will be "unique" and hence not considered a
+//     secure protocol. (This is important because SchemeRegistry treats "data"
+//     as a secure protocol).
+//
+// Source a <script src="https://secure/foo.js"> but the server redirects to a
+// data:URL
+//   * The script will not be granted access.
+//   * Although in practice it was delivered over a secure transport, blink
+//     considers the script to have a "unique" SecurityOrigin.
+//
+// Create a "new Worker('data:..')" from within a http://evil document
+//   * WebWorker should NOT be granted access
+//   * In practice this is an invalid test -- specifying a data:URL for a
+//     WebWorker script is not supported. If it were however, then it should
+//     NOT be granted access.
+//
+// Create a "new Worker('http://evil/foo.js')" from within an https://secure
+// document.
+//   * WebWorker should be granted access
+//   * This will trigger a mixed content warning however.
+//
+// Create an <iframe src="data:..."> from within a https://secure document
+//   * In practice this is going to deny access, because Blink gives the
+//     iframe a SecurityOrigin of "unique". In theory though, the script source
+//     was delivered over a secure transport so this could be granted access.
+//
+// Create an <iframe sandbox="allow-scripts allow-same-origin" src="data:...">
+// within a https://foo/ document.
+//   * The iframe will be granted access.
+//
+// Create an <iframe sandbox="allow-scripts"> from a https://foo document
+//   * The resulting page should NOT be granted access
+//   * The iframe document's SecurityOrigin will be "unique"
+//
+// Click on a link to a data:URL linked within an http://evil document
+//   * The resulting page should NOT be granted access
+//   * The new document's SecurityOrigin will be "unique".
+//
+// Enter a data:URL directly into the omnibox, for a mimetype of text/html
+//   * In theory access could be granted since the content came locally.
+//     However in practice this is treated the same as clicking a link to a
+//     data:URL.

[abarth-chromium, 2014/06/06 20:36:34]

Please remove this comment.  If you want to have this much exposition, you can
put it on the wiki page referenced on the first line of the comment.

[eroman, 2014/06/10 01:00:11]

Done.

+bool SecurityOrigin::canAccessFeatureRequiringSecureOrigin() const
+{
+    if (isLocal())
+        return true;
+
+    // It is not possible for m_protocol to be "data" here. But if it
+    // is, then SchemeRegistry will incorrectly treat it as secure, so
+    // defensively reject it.
+    if (m_protocol == "data")
+        return false;

[abarth-chromium, 2014/06/06 20:36:34]

Generally, we don't include dead code in the product.  If you like, you can
ASSERT(m_protocol != "data");  If you're really worried, you can use
RELEASE_ASSERT instead.

[eroman, 2014/06/10 01:00:11]

Done.

+
+    if (SchemeRegistry::shouldTreatURLSchemeAsSecure(m_protocol))
+        return true;
+
+    // FIXME: http://crbug.com/362214
+    // The localhost check should be more relaxed and allow all of 127/8 and
+    // ::1/128.
+    if (!m_protocol.isEmpty() && !m_domainWasSetInDOM && (m_domain == "localhost" || m_domain == "127.0.0.1" || m_domain == "[::1]"))
+        return true;

[abarth-chromium, 2014/06/06 20:36:34]

Using m_domain here is incorrect.  You want to use m_host.

It can't be right to tread 127.0.0.1 differently than 127.0.0.2.  Also, this
should be extracted into a helper function.

[eroman, 2014/06/10 01:00:11]

Done.

+
+    return false;
+}
+
 SecurityOrigin::Policy SecurityOrigin::canShowNotifications() const
 {
     if (m_universalAccess)