Lock down the registration of blob:chrome-extension:// URLs

chrome/browser/DEPS

Index: chrome/browser/DEPS
diff --git a/chrome/browser/DEPS b/chrome/browser/DEPS
index 05dc019bd0f245487c02fd57860130ef4d54cf49..30356174b7389ff41592c360e41b72c3671842c1 100644
--- a/chrome/browser/DEPS
+++ b/chrome/browser/DEPS
@@ -104,3 +104,11 @@ include_rules = [
   "+third_party/WebKit/public/web/WebTextDirection.h",
   "+third_party/WebKit/public/web/WebWindowFeatures.h",
 ]
+
+specific_include_rules = {
+  # Exploits don't abide by DEPS; so all IPC message definitions are fair game
+  # in this type of test.
+  'chrome_security_exploit_browsertest\.cc' : [
+    '+content/common',

[jam, 2016/10/04 23:28:54]

we never allow includes from within content from outside, even for tests.

Can you wrap the code you need with a helper method in content/public/test and
then call that from the browsertest?

[ncarter (slow), 2016/10/05 18:22:09]

Hi John -- can you respond to the argument made on line 109? Exploits are
usually layering violations by definition; the bug under test here is a bug in
//content, that's can only be reproed in //chrome (because extensions) and the
fix lives in //extensions.

Charlie, nasko and I had discussed this before carving out this exception, and
it all seemed reasonable to us.

Test methods like you suggest are possible, but I'd need several of them per
test, and they have no chance of reusability, and they just seem like the
restriction ties the hands of testwriters here. We need to make these sorts of
cases easier to test, not harder; curious if you have any ideas for ways to do
that that also fit inside our layering goals for the architecture.

[jam, 2016/10/05 19:11:08]

I don't really grep this sentence; it all depends on how you define layering
violations.

Regardless of the semantics though, there are way of testing this without having
chrome reach into the internals of content by using public methods. This is the
pattern we've used for several years, so I don't see a reason to change that
now.
Sure, that's fine.
I'm not sure how the fact that we have non-reusable test methods affects things?
It's a small effort to create public methods for this, so it's not a large
overhead.
Why does have having a public test method restrict test authors?
Agreed we need more tests, however no need to break the separation of chrome vs
content internals that we've spent a few years creating, and then have
maintained for a few years since.

[ncarter (slow), 2016/10/05 20:45:34]

I'm saying that an attacker doesn't have to ask OWNERS for permission 
to use an IPC in an exploit chain.
I see a sharp distinction between security exploit tests and other type of
tests. I agree with your statement strongly when applied to the latter. But for
the former, this restriction makes about as much sense as requiring a fuzzer's
output to comply with the js style guide.

Maybe these types of tests belong in their own target?
Mostly I'm making a productivity argument. It's more work to do the same thing,
so it makes experimentation harder. If we allow the #includes, we basically
create an environment where it's straightforward to spoof any message, without
adding a helper method to content/public/test for each method. In my view, such
an environment encourages testwriting. Also, if the messages aren't in content/,
but somewhere else, using the IPC message in this way might require creating a
test_util target.

I don't know if we have a PwnMessageReceived story figured out for mojo yet, but
in a mojo world, I would hope that chrome_security_exploit_browsertest should
have access to an internal Mojo interface that normally we would want to hide
from a chrome browsertest.
If you are an attacker, there is no separation of chrome vs. content internals.

+  ],
+}