From a security POV this doesn't seem terribly interesting (the attacker must convince the user to add a dangerous bookmarklet, navigate to a privileged page, and invoke the bookmarklet). 

But the finder is correct in noting that navigation to javascript: URIs is blocked on chrome:// tabs on desktop platforms.

Tactically, this could be fixed by updating loadJavaScriptFromLocationBar to look at the current tab's URL and cancel the script-load operation if the tab is located on a prohibited scheme. That would cover both user-entered JS and bookmarks.

marq: could you please help us find an appropriate owner for this? It looks like it's iOS specific.

cc sky@ for bookmarks

any follow-ups on this issue?

Hello,are experts following up on this issue?

Sorry for the delay in updating this. Assigning to eugenebut@.

@marq OK,thank you very much

Bookmarks code calls |loadJavaScriptFromLocationBar:|:
https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/bookmarks/bookmark_interaction_controller.mm?q=loadJavaScriptFromLocationBar+package:%5Echromium$&l=305

Chris, what do you think about allowing Bookmarklets on iOS from a security perspective?

Whether or not we support bookmarklets, and if they should be able to mess with WebUI (chrome://*) origins, are product design decisions that are not really in my bailiwick.

It seems to me that bookmarklets (if we support them) shouldn't be able to mess with WebUI. If there is a security issue here, it's that.

Thank you. Desktop does not allow running JavaScript for WebUI pages, so I'm just add the same limitation for iOS.

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

commit cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe
Author: eugenebut <eugenebut@chromium.org>
Date: Thu Mar 23 18:17:55 2017

Disallow JS execution on WebUI pages.

As a side effect TapWebViewElementWithId now actually opens windows instead of
popups, which is definitely a correct behavior.

BUG= 692378 

Review-Url: https://codereview.chromium.org/2761173002
Cr-Commit-Position: refs/heads/master@{#459149}

[modify] https://crrev.com/cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe/ios/chrome/browser/ui/settings/block_popups_egtest.mm
[modify] https://crrev.com/cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe/ios/chrome/browser/ui/toolbar/toolbar_egtest.mm
[modify] https://crrev.com/cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe/ios/web/public/test/web_view_interaction_test_util.mm
[modify] https://crrev.com/cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe/ios/web/web_state/ui/crw_web_controller.mm
[modify] https://crrev.com/cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe/ios/web/web_state/ui/crw_web_controller_unittest.mm
[modify] https://crrev.com/cfe21b64486c2a1bfed6e0e7304fcf8f1748ccfe/ios/web/web_state/ui/web_view_js_utils.h

This bug requires manual review: Less than 29 days to go before AppStore submit on M58
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

Hello,can this Reward-topanel?

And I aware that the title of the report maybe inappropriate,could you help me to change this title to be appropriated?such as:"Security:iOS chrome allow JS execution on domain chrome:// WebUI pages"

Oh,sorry,I misspelled a word.It may cause ambiguity. "appropriated" =>"appropriate"

awhalley@ is this a candidate for "Reward-topanel"?

I'm afraid as a low severity bug it's likely out of scope of the Chrome VRP, but adding the label for consideration.

Verified on M59.0.3054.0 canary
Device: iPhone7, iPhone6 plus
iOS: 10.3, 10.1.1

Bookmarklets are not executed in Chrome pages.
Bookmarklets continues to work as usual in regular webpages.

I'm afraid the panel declined to award for this bug. Many thanks for the submission though!

But another low security bug has rewarded to panel(CVE-2016-5193),it also just a small bug in iOS.
Could you think about it again?please.

Hi zyzengstorm@. Low bugs end up going to the panel only when they are borderline; that one ended up falling on the reward side, this one not. See elawrence@'s comments in #1 about why we think this is very much a low severity issue.  However, since it was in shipping Chrome and we made a fix, it will get a CVE and release noted - how would you like to be credited?

@awhalley OK,thank you for your detail explanation.

Please credit to "Zhiyang Zeng of Tencent security platform department"

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