Implement security enforcements for sandboxed frame processes.

With OOPSIFs, it becomes possible to tighten security checks for
processes that host sandboxed frames. Namely, sandboxed frames have an
opaque origin and cannot access storage, passwords, cookies and
various other forms of data. This CL implements this restriction with
an additional check in CanAccessMaybeOpaqueOrigin() that's specific to
sandboxed frame processes, blocking all access to an existing origin's
data coming from a sandboxed process. Two other types of access are
still permitted:

- new URLs are still allowed to commit in sandboxed frames. Ideally,
  we would also enforce that this requires the URL to commit with an
  opaque origin, but currently this knowledge is not plumbed from
  all the callers (namely, CanCommitURL and CanCommitOriginAndUrl).
  This will be fixed in subsequent CLs.

- using a particular origin as an initiator origin (for example, in
  postMessage) is still allowed, as long as that origin is
  opaque. This is because sandboxed frames are still allowed to
  communicate with other frames and send/receive messages. Note that
  there are still some workarounds [1] in place that exclude opaque
  origins from performing ChildProcessSecurityPolicy security checks
  in the first place, which also will be removed in future CLs.

Here is a summary of current uses of CanAccessDataForOrigin(), as well
as why these are all safe to block in sandboxed frames, which is what
this CL does:

- DOM storage, such as localStorage, sessionStorage, or web
  databases. These are not allowed in opaque origins.

- Passwords. Blink already enforces that opaque origins already cannot
  access passwords [2], so this is just adding a browser-side
  enforcement.

- cookies (the common path does not use CanAccessOrigin() and protects
  cookie access by construction, but one Android-specific media path
  currently still uses CanAccessOrigin() to protect cookie
  access). Cookies can't be accessed by opaque origins.

- blob URL access. Blob URLs *can* be created in sandboxed frames (and
  will have an opaque origin as a result), but after a recent blob URL
  refactor (see net::features::kSupportPartitionedBlobUrl), that
  doesn't go through CanAccessOrigin() checks. Only the old mode
  (already disabled by default) still uses CanAccessOrigin(), and
  specifically skips it for opaque origins [3]. Hence, it should be
  safe to just treat blob URLs the same as any other type of storage
  from CPSP's perspective.

- Push messaging access. These require ServiceWorkers to run in the
  corresponding origin, but ServiceWorkers are blocked for sandboxed
  frames: see code [4] and spec [5].

- Plugins. Plugins can't be loaded in sandboxed frames, and there's no
  directive to bypass that restriction [6].

[1] https://source.chromium.org/chromium/chromium/src/+/main:content/browser/renderer_host/render_frame_proxy_host.cc;l=549;drc=79fd5d71c46d0e6ecd842867bc1c787fae68e218

[2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/weborigin/security_origin.h;l=240;drc=79fd5d71c46d0e6ecd842867bc1c787fae68e218

[3] https://source.chromium.org/chromium/chromium/src/+/main:storage/browser/blob/blob_registry_impl.cc;l=639;drc=b5b5329172a1607685db895653aa928560848ed3

[4] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/service_worker/navigator_service_worker.cc;l=36;drc=a5a3f3a8599e454645674a6de1a54660c34f8faf

[5] https://www.w3.org/TR/service-workers/#control-and-use-window-client

[6] https://web.dev/articles/sandboxed-iframes.

Change-Id: I4ae23c9eef75540ac96d0cfac699272a49152cf9
Bug: 325410297
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5282423


Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Ayu Ishii <ayui@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1280332}