New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 700882 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

Use webpage to load "chrome://newtab"

Reported by zyzengst...@gmail.com, Mar 13 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce the problem:
1. open this page:

#1:<a href="https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8" target="_blank">https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8</a><br><br>
#2:<a href="about:newtab" target="_blank">about:newtab</a><br><br>
#3:<a href="chrome://newtab" target="_blank">chrome://newtab</a>

2. You will find #1 can open a newtab directly,and others cannot.

Is this a new feature in canary?I don't know it.But,I found #1 return a 307 code,then redirect to chrome://newtab.

What is the expected behavior?
open "about:blank" or open nothing

What went wrong?
A webpage open "chrome://newtab" successfully

Did this work before? N/A 

Chrome version:  59.0.3040.0  Channel: canary
OS Version: OS X 10.12.3
Flash Version: Shockwave Flash 24.0 r0
 
It's source code of POC page in reproduce step 1.
Cc: elawrence@chromium.org
Components: UI>Browser>NewTabPage
Labels: OS-Chrome OS-Linux OS-Windows
Status: WontFix (was: Unconfirmed)
This behavior has existed for some time and is working as intended; if you can find a way to do something devious with this, please update the Issue.

Blocking navigation to chrome://newtab is a part of a general block of all navigations to chrome:// protocol URLs; there's no particular goal to block that URL, and as you report, you can mimic its effect by navigating to the default "new tab page" URL on Google's website.

The https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8 page is "special" insofar as the 

HandleNewTabURLRewrite handles rewriting chrome://newtab into the proper URL of the user's new tab page.

NewTabPageInterceptor handles detection of navigation to the user's new tab page and, if found, possible redirection of the navigation to the user's local New Tab Page; that redirection is shown as a HTTP/307 to chrome::kChromeSearchLocalNtpUrl in the network tools even though the 307 didn't come from the network (see MaybeInterceptResponse). The NewTabPage search URLs result in special behavior, see SearchTabHelper::UpdateMode.
Hello,thank you for your detail description.

I retest another POC:

<form action="https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8" method="POST">
<input type="submit" name="submit">
</form>

this can load "chrome-search://local-ntp/local-ntp.html" directly,not still "https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8"


from 1.png you can see this poc has load chrome-search://local-ntp/local-ntp.html

from 2.png you can see other newtab's location is still https://www.google.com/_/chrome/newtab?espv=2&ie=UTF-8
Project Member

Comment 4 by sheriffbot@chromium.org, Jun 20 2017

Labels: -Restrict-View-SecurityTeam allpublic
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

Sign in to add a comment