Interesting. I'm not convinced that this is very interesting from a security point-of-view; the permission so granted would allow the extension to interact with pages that use spoofy IDN domains, but this wouldn't impact the omnibox in any way, and the origin of the extension itself isn't in any way misrepresented.

Any thoughts Devlin?

I'm also dubious about the security aspect of this (accessing spoofy-google actually sounds quite a bit less harmful than accessing real-google and stealing my data), but I'd be supportive of a change for consistency and clarity.

mkwst@, is there a preferred canonicalization function to use for things like this?

I believe url_formatter::FormatUrlForSecurityDisplay is the function to use.

As I understand this, the impact is that a user might think they're agreeing to execute scripts from google.com, and the extension will actually execute scripts from evil-google.com. Now there are a number of qualifiers on this including that the extension could just include the scripts directly, and that it's bound to it's own spoofed domain name. I'll tag this as low.

RE #5: I thought the Permissions node in the manifest gates what domains the extension is allowed to access and script /against/, not what domains the extension is allowed to source SCRIPTS /from/. I wasn't aware of restrictions (aside from the manifest's CSP, if any) on where an extension can source script from?

RE #8 this is a fair point, in my testing it seems the CSP is the only factor inhibiting an extension from loading scripts from a third-party domain. However, an attacker still has the ability to coerce users into accepting permissions to access and modify content on domains they were not expecting which could aid in deception attacks.

catmullings@, this could be a good one for you to tackle.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/504e0c45030f76bffda93f0857e7595216d6e7a4

commit 504e0c45030f76bffda93f0857e7595216d6e7a4
Author: Catherine Mullings <catmullings@chromium.org>
Date: Fri Sep 01 01:04:46 2017

Ensure IDN domains are in punycode format in extension host permissions

Today in extension dialogs and bubbles, IDN domains in host permissions
are not displayed in punycode format. There is a low security risk that
granting such permission would allow extensions to interact with pages
using spoofy IDN domains. Note that this does not affect the omnibox,
which would represent the origin properly.

To address this issue, this CL converts IDN domains in host permissions
to punycode format.


Bug:  745580 
Change-Id: Ifc04030fae645f8a78ac8fde170660f2d514acce
Reviewed-on: https://chromium-review.googlesource.com/644140
Commit-Queue: catmullings <catmullings@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/heads/master@{#499090}
[modify] https://crrev.com/504e0c45030f76bffda93f0857e7595216d6e7a4/chrome/common/extensions/permissions/chrome_permission_message_provider_unittest.cc
[modify] https://crrev.com/504e0c45030f76bffda93f0857e7595216d6e7a4/extensions/common/DEPS
[modify] https://crrev.com/504e0c45030f76bffda93f0857e7595216d6e7a4/extensions/common/permissions/permission_message_util.cc

The VRP panel look at look at this bug, but I'm sorry to say declined to reward (as is usually the case for low severity bugs).  But thanks for the report!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot