New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Fixed
Closed: Oct 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Security: HTTPS Address Bar Spoofing Using View-source And Redirection
Reported by, Oct 4 2011 Back to list

  There is an inconsistency in the way Google Chrome renders some web page 
  redirections in a way that allows an attacker to perform address bar 
  spoofing, resulting in an HTTPS URL being displayed with the content 
  from some other web site. Let's take, for example, a simple javascript 
  redirection page located at http://source/sample.html that looks as 

  When observing the above sample in execution all parts of UI behave 
  consistently, meaning that as the address bar changes from URL of the 
  source page to the target URL, the page content changes accordingly and 
  promptly (at once). However by altering the script like this:
  one can see the address bar starts changing before the source page 
  content gets replaced by a new canvas. So for a split second the address 
  bar displays "http://target" while the DOM is still from 
  "http://source/sample.html". The given example is composed of 2 tricks:
  1)Apparently the view-source: prefix causes the asynchronous behavior 
  between address bar and the DOM.

  2)The redir.php is a HTTP 302 redirection script used to cause a 
  redirect from "view-source:http://source/redir.php" to "http://target", 
  thus removing the "view-source:" prefix from the URL (the goal is to 
  spoof the address bar to a legitimate domain as will be shown later). 
  Also, after redirection, the browser no longer tries to display the 
  source code but renders the HTML of "http://target".

  All demos (available from address below) employ the above 2 tricks with 
  http://target replaced by a Gmail login page address. However, to stop 
  the redirection at the exact moment when the inconsistency between the 
  address bar and the page contents is being exhibited, a further trick is 

  In ABS1.php, is used as target of the 
  redir.php script to block the redirection for about 30 seconds (After 
  that an error page is displayed as Chrome decides that it cannot 
  establish an SSL/TLS connection with the server on port 80). At the same 
  time as the redirection "view-
  om:80/" is triggered, a form with a text field is displayed simulating a 
  fake login page. If text is entered and the submit button is pressed the 
  data gets sent to  Tests have shown that 
  instead of an unresponsive server script can 
  be used or an invalid target URL such as view-source:http://source. 

  In ABS2.php, we avoid the suspicious :80 port by using any open redirect 
  present on https://* as the desired spoof URL. The demo is 
  analogous to the previous except that an additional redirect is used 
  after the script and the is replaced by a download-throttling page that delays the loading for an 
  arbitrary amount of time. This time the URL that the redirection gets 
  stuck on is[...].   
  In ABS3.php we manage to spoof the exact URL string of the Gmail login 
  page. To do that a modal dialog is used to stop the redirection instead 
  of the "wrong port trick" as in or the 
  download-throttling slow.php mentioned above. A precondition however is 
  that the victim has come to from the 
  spoofed-to-be host (in our case or another 
  host in its 2nd level domain (either via search results or a redirection 
  script) before address bar spoofing redirection begins and a modal 
  dialog can stop it (step 1). In step 2 a similar redirection is launched 
  as in the previous demo, but with the following differences:
  -a blocked (pinned) modal dialog is used to stop the redirection at the 
  right moment. Like in the previous demo a fake login form is displayed, 
  but any requests resulting from its submit button being pressed are 
  queued for the life time of the modal dialog. Therefore a "self 
  destruction" javascript is in place inside the modal dialog that 
  triggers after the submit button has been pressed, thus releasing the 
  said queue and allowing the credentials to be sent to attacker's server. 
  -a more convincing URL is used as target of 
  the redir.php script, avoiding the :80 port trick and the slow.php trick 
  from previous demos.
  All three demos are available here as on-the-fly links:
  For further clarification of each individual demo, open their individual 
  pages in Chrome and follow the on-screen step by step instructions:
   Demo 1: 

   Demo 2: 

   Demo 3:
  Of course, in a real world attack the described demos would be presented 
  to the victim as "click me" URLs enveloped as redirect URLs from without further interaction needed.
  In summary, we found ways to get Chrome to display an HTTPS URL from one 
  host while displaying the content from another host. Note that the icon 
  left to the URL is a grey planet as is typical for HTTP addresses - and 
  not a green lock as is typical for valid HTTPS addresses. However, while 
  many users may notice the "https" and consider it as a guarantee of 
  trust, they are less likely to notice the *absence* of a lock -
  especially since the visual identification of HTTPS URLs is different in 
  different web browsers. In addition, while users could notice a crossed-
  over lock icon (shown on HTTPS web sites that seem suspect), a grey 
  planet icon does not indicate any danger.
  Chrome Version: v14.0.835.187+stable,16.0.891.0+dev-m
  Operating System: Windows XP, Version  5.1.2600 Service Pack 3 Build 2600
                    Windows 7 Professional SP1

Labels: -Pri-0 -Area-Undefined Pri-1 Area-Internals SecSeverity-High OS-All Mstone-14
Status: Available
@creis - It sounds like a redirect from view-source triggers the case of the omnibox getting updated before the load commits. Can you cover this one, or should someone else?
Comment 2 by, Oct 4 2011
Status: Assigned
Yes, I can take a look at this one.
Comment 3 by, Oct 7 2011
Status: Started
I've been looking at this one and I have a draft of a fix, but I'm still trying to understand all of the corner cases.

The root problem here is that NavigationController::GetVisisbleEntry is showing the pending_entry_ for certain renderer-initiated navigations.  As these spoofs demonstrate, we should not show the pending URL for renderer-initiated navigations.  In most cases, we have no pending_entry_ for renderer-initiated navigations, so this bug doesn't happen on most link clicks.

The problem only occurs when the renderer punts a navigation to the browser to force a process swap.  That happens with view-source links (as shown here), but also in transitions between extensions/apps and normal pages.  I think you could see the same results going from a non-app page to a URL of an installed hosted app.

I have a fix that checks if the pending_entry_ has a transition_type() of PageTransition::LINK, in which case we should not show it in GetVisibleEntry.

I originally thought I should make an exception for cases where the link is opened in a new tab.  In that case, there's no committed entry and it felt strange to show "about:blank" until the slow page committed.  It turns out that's unsafe-- the attacker can control the contents of the "about:blank" tab until the slow page commits (e.g., using w =; w.document.body.innerHTML += "foo").

Even though it feels counter-intuitive, I think we need to keep showing "about:blank" while the new tab is loading.

I'm continuing to investigate corner cases with interrupted navigations and omnibox prerendering to see if anything goes wrong there.  Should have a CL for review soon.
Comment 4 by, Oct 7 2011
CC'ing Dominic for the omnibox prerendering issue.  My fix ends up hiding the URL when that's enabled because the prerendering logic always uses LINK (rather than PageTransition::TYPED in the omnibox case).  That's now filed separately in  issue 99542 .
Omnibox prerendering issue fixed in r104756.
Comment 6 by, Oct 10 2011
Thanks for the quick change, Dominic!
Comment 7 by, Oct 10 2011
Labels: -Mstone-14 Mstone-15 SecImpacts-Stable SecImpacts-Beta Merge-Approved
Status: FixUnreleased
Flagging for merge to 874:
Comment 8 by, Oct 10 2011
Status: Started
Sorry, it's not fixed yet.  Dominic's CL was just something blocking the fix I'm working on.
Comment 9 by, Oct 10 2011
Labels: -Merge-Approved
Ah, sorry, jumped the gun. I should give you at least another five minutes to finish off the patch. ;)
Project Member Comment 10 by, Oct 10 2011
The following revision refers to this bug:

r104756 | | Mon Oct 10 12:16:37 PDT 2011

Changed paths:

Use TYPED PageTransition for Omnibox prerendering.

BUG= 99542 , 99016 
TEST=UnitTest: Prerender*, BrowserTest: Prerender*

Review URL:
Comment 11 by, Oct 11 2011
A CL to fix this is in review:
Project Member Comment 12 by, Oct 13 2011
The following revision refers to this bug:

r105355 | | Thu Oct 13 12:48:34 PDT 2011

Changed paths:

Don't show URL for pending new navigations initiated by the renderer.

BUG= 99016 
TEST=Click a link to a slow view-source: URL.

Review URL:
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Merge-Approved
Status: FixUnreleased
This one, we might want to let it roll in m16.
Comment 14 by, Oct 13 2011
Yeah, I was going to mention something about that.  With the number of files it touches (even though most are just adding an extra parameter), it wouldn't be easy to merge to M15.  We just didn't have enough info to fix the bug without the new parameter.
Project Member Comment 15 by, Oct 14 2011
The following revision refers to this bug:

r105577 | | Fri Oct 14 14:11:02 PDT 2011

Changed paths:

Fix memory error in previous CL.

BUG= 100315 
BUG= 99016 
TEST=Memory bots go green

Review URL:
Comment 16 by, Oct 17 2011
Labels: -Mstone-15 -Merge-Approved Mstone-16
Labels: reward-1000 reward-unpaid
@mitja.kolsek: thanks for this report. It does look like a valid URL spoofing bug, and the report quality was high. For this combination, we offer a $1000 Chromium Security Reward. Thanks again!

Boilerplate text:
Please do NOT publicly disclose details until a fix has been released to all our
users. Early public disclosure may cancel the provisional reward.
Also, please be considerate about disclosure when the bug affects a core library
that may be used by other products.
Please do NOT share this information with third parties who are not directly
involved in fixing the bug. Doing so may cancel the provisional reward.
Please be honest if you have already disclosed anything publicly or to third parties.
@scarybeasts: Thanks. When do you expect this issue to be fixed? 
Hey guys, could you please correct the acknowledgments for this issue (CVE-2011-3907) at so that instead of my name, it would state "Luka Treiber of ACROS Security"?

I only reported this to you, Luka did the heavy lifting.

Thanks a lot!
 Issue 75559  has been merged into this issue.
Labels: -reward-unpaid
Payment is in e-system. Give it a week or two for the wire to execute.
Comment 22 by, Feb 22 2012
Comment 23 by, May 15 2012
Status: Fixed
Marking old security bugs Fixed..
Project Member Comment 24 by, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 25 by, Mar 10 2013
Labels: -Type-Security -Area-Internals -SecSeverity-High -Mstone-16 -SecImpacts-Stable -SecImpacts-Beta Security-Impact-Stable Security-Impact-Beta Cr-Internals Security-Severity-High Type-Bug-Security M-16
Project Member Comment 26 by, Mar 13 2013
Labels: Restrict-View-EditIssue
Project Member Comment 27 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member Comment 29 by, Mar 21 2013
Labels: -Security-Severity-High Security_Severity-High
Project Member Comment 30 by, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 31 by, Mar 21 2013
Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member Comment 32 by, Jun 14 2016
Labels: -security_impact-beta
Project Member Comment 33 by, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member Comment 34 by, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment