The documentation (https://support.google.com/chrome/a/answer/2657289?hl=en) certainly seems to imply that blocking should take place for *all* blacklisted resources.

However, URLBlacklistManager::IsURLBlocked seems to only be called by  URLBlacklistManager::ShouldBlockRequestForFrame via ChromeNetworkDelegate::OnBeforeURLRequest which checks if the target resource is a frame.

atwilson, can you take a look at this or give it to the right person?

I don't think this is a security vulnerability per se; it's more of a functional bug in a management feature.

Also, is this behavior intended, or is it actually a bug?

Interesting - the help center article differs from the official policy documentation. The official documentation (http://www.chromium.org/administrators/policy-list-3#URLBlacklist) says:

"This policy prevents the user from loading web pages from blacklisted URLs"

It says nothing about subresource loads, loading of javascript libraries from public repositories, etc - the intent was to block top-level website loads.

David/Max - in principle, we should make the URL blacklist more stringent and have it block all resource loads, not just top level frames. However, changing this behavior will almost certainly have unexpected consequences/break some sites and it's not clear that the current behavior is an issue in practice with any customers. And no matter what, there's nothing we can really do to prevent some extension from writing its own HTTP stack and directly loading resources over a TCP socket.

What would you like to do here? Change the behavior, or update the help center article to reflect the current behavior?

If there are acceptable ways to circumvent the blacklist, would that not nullify the purpose of the blacklist? Installed extensions can be managed within a public session, so that should not be much of a problem. This issue though cannot currently be prevented.

I agree this is not a security issue per se, but I do think it requires some attention. As an example, enterprises often use blacklists for known malicious domains and a persistent XSS attack would not exclude it from being accessed.

An elegant solution would be to have a secondary policy (disabled by default to not cause issues with current customers?) that also blocks subresources.

I think we should fix the behavior, but this seems like a very low priority issue since it's not the main use case for the policy.