CORS-RFC1918: Pipe creator address space through SharedWorker creation.

CORS-RFC1918: Pipe creator address space through SharedWorker creation.

SharedWorkers are created in a fairly arcane process whereby the renderer
IPCs up to the browser to look for existing workers, and then the browser
IPCs back down to the renderer to kick off a request if a new worker needs
to spin up. https://codereview.chromium.org/1760523004 took care of some
of the work necessary to ensure that the worker that spins up is correctly
marked as "external" if relevant, but didn't deal with the request for the
worker itself.

"Why do we care?", you ask, "Surely SharedWorkers are same-origin with the
requesting page!" True, but part of the goal is to deal with DNS poisoning
attacks, which means that we really do need to tag the request itself.
Ugh.

The CL is large enough, but got even larger when I realized that I needed
to split the AddressSpace enum out of WebURLRequest in order to make it
includable from //content/{browser,common}. Sorry for the mess!

As kinuko@ noted in the previous patch, unit tests that generate a request
I could verify are hard to put together with the current infrastructure.
There's an upcoming patch (https://codereview.chromium.org/1745083002)
which breaks the existing //security/cors-rfc1918/* layout tests without
this patch, however.

BUG=591052
Committed: https://crrev.com/cfa9893483f1c8b83d9e93c188c4c18f552bb1ba
Cr-Commit-Position: refs/heads/master@{#380126}

[Mike West, 2016-03-08 13:50:49]

mkwst@chromium.org changed reviewers:
+ jochen@chromium.org, kinuko@chromium.org

[Mike West, 2016-03-08 13:50:50]

Hello, kinuko@ and jochen@! This patch isn't as big as it looks, I swear!

kinuko@: Would you please review the work to pipe the address space value
through the shared worker creation mechanism? It looks huge, but it's mostly
mechanical and boring. :/

jochen@: Would you review the DEPS changes in //content, as well as the Blink
pieces that are related to extracting WebAddressSpace from WebURLRequest?
Basically, everything that's not worker-related.

Thanks!

[kinuko, 2016-03-08 15:53:56]

Whoa. I see that's mostly for plumbing... lgtm

https://codereview.chromium.org/1775933002/diff/20001/content/browser/shared_...
File content/browser/shared_worker/shared_worker_instance_unittest.cc (right):

https://codereview.chromium.org/1775933002/diff/20001/content/browser/shared_...
content/browser/shared_worker/shared_worker_instance_unittest.cc:84: for (int i
= 0; i < 3; i++) {
Maybe 

i = 0; i <= static_cast<int>(WebAddressSpaceLast); i++

?

[jochen (gone - plz use gerrit), 2016-03-08 16:11:46]

lgtm

[Mike West, 2016-03-09 07:16:45]

The CQ bit was checked by mkwst@chromium.org

[Mike West, 2016-03-09 07:16:45]

The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1775933002/#ps40001
(title: "kinuko@")

[commit-bot: I haz the power, 2016-03-09 07:17:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1775933002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1775933002/40001

[commit-bot: I haz the power, 2016-03-09 07:33:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-09 07:33:47]

Try jobs failed on following builders:
  linux_chromium_gn_chromeos_rel on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mike West, 2016-03-09 11:18:14]

The CQ bit was checked by mkwst@chromium.org

[Mike West, 2016-03-09 11:18:14]

The patchset sent to the CQ was uploaded after l-g-t-m from kinuko@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1775933002/#ps60001
(title: "typo")

[commit-bot: I haz the power, 2016-03-09 11:18:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1775933002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1775933002/60001

[commit-bot: I haz the power, 2016-03-09 13:06:29]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-03-09 13:08:05]

Description was changed from

==========
CORS-RFC1918: Pipe creator address space through SharedWorker creation.

SharedWorkers are created in a fairly arcane process whereby the renderer
IPCs up to the browser to look for existing workers, and then the browser
IPCs back down to the renderer to kick off a request if a new worker needs
to spin up. https://codereview.chromium.org/1760523004 took care of some
of the work necessary to ensure that the worker that spins up is correctly
marked as "external" if relevant, but didn't deal with the request for the
worker itself.

"Why do we care?", you ask, "Surely SharedWorkers are same-origin with the
requesting page!" True, but part of the goal is to deal with DNS poisoning
attacks, which means that we really do need to tag the request itself.
Ugh.

The CL is large enough, but got even larger when I realized that I needed
to split the AddressSpace enum out of WebURLRequest in order to make it
includable from //content/{browser,common}. Sorry for the mess!

As kinuko@ noted in the previous patch, unit tests that generate a request
I could verify are hard to put together with the current infrastructure.
There's an upcoming patch (https://codereview.chromium.org/1745083002)
which breaks the existing //security/cors-rfc1918/* layout tests without
this patch, however.

BUG=591052
==========

to

==========
CORS-RFC1918: Pipe creator address space through SharedWorker creation.

SharedWorkers are created in a fairly arcane process whereby the renderer
IPCs up to the browser to look for existing workers, and then the browser
IPCs back down to the renderer to kick off a request if a new worker needs
to spin up. https://codereview.chromium.org/1760523004 took care of some
of the work necessary to ensure that the worker that spins up is correctly
marked as "external" if relevant, but didn't deal with the request for the
worker itself.

"Why do we care?", you ask, "Surely SharedWorkers are same-origin with the
requesting page!" True, but part of the goal is to deal with DNS poisoning
attacks, which means that we really do need to tag the request itself.
Ugh.

The CL is large enough, but got even larger when I realized that I needed
to split the AddressSpace enum out of WebURLRequest in order to make it
includable from //content/{browser,common}. Sorry for the mess!

As kinuko@ noted in the previous patch, unit tests that generate a request
I could verify are hard to put together with the current infrastructure.
There's an upcoming patch (https://codereview.chromium.org/1745083002)
which breaks the existing //security/cors-rfc1918/* layout tests without
this patch, however.

BUG=591052

Committed: https://crrev.com/cfa9893483f1c8b83d9e93c188c4c18f552bb1ba
Cr-Commit-Position: refs/heads/master@{#380126}
==========

[commit-bot: I haz the power, 2016-03-09 13:08:06]

Patchset 4 (id:??) landed as
https://crrev.com/cfa9893483f1c8b83d9e93c188c4c18f552bb1ba
Cr-Commit-Position: refs/heads/master@{#380126}