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 1 user

Issue metadata

Status: Fixed
OOO Aug 10-27
Closed: Apr 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

URL Bar Spoofing using redirection and location.reload();

Reported by, Mar 29 2011

Issue description

URL Bar Spoofing using redirection and location.reload() 

Chrome Version: [10.0.648.204] + [stable, beta, or dev]
Operating System: [windows 7 and Mac]


Click on the button , when you see on title of tab , open a new tab , look to the previous tab , the URL Bar show with the previous content.

43.4 KB View Download
It's a webkit vulnerability.

Comment 2 by, Mar 29 2011

Cc: a deleted user
This looks very similar to  bug 76666 .

@creis - You seem to be the one most active in this area. Could you take a look?

Comment 3 by, Mar 29 2011

Status: Untriaged
I tested it out, and I can still repro it after the fix for  issue 76666 .  I can take a closer look to see if it's related, though.

Comment 4 by, Mar 30 2011

The problem seems to be related to TabContents::OnDidRedirectProvisionalLoad.

The test page has a button that reloads the page.  The server seems to randomly decide to redirect to every few requests, so sometimes the reload ends up being a redirect.  This causes OnDidRedirectProvisionalLoad to update the URL of the current NavigationEntry to

However, the test page uses a JavaScript timer to stop the load before it finishes.  At this point, we don't fix the NavigationEntry, so switching tabs away and back makes us display as the URL.

Brett, I think you're more familiar with the NavigationEntry logic than me.  Is there a way we can reset the NavigationEntry's URL if the load aborts?  It looks like we're just forgetting the original URL right now...
I think the SecSeverity is Medium.

Comment 6 by, Mar 30 2011

I'm surprised we're modifying the URL on redirects, I don't think this is correct at all.

I checked the provenance of this code, which I imagined was checked in recently by somebody who didn't understand something trying to work around some subtle bug. However, it dates back to the very first open sourcing of Chromium!
(search for DidRedirectProvisionalLoad).

I can't think of a good reason we should be updating the URL when the provisional load is redirected. TabContents shouldn't be doing that kind of computation anyway (it should be the NavigationController), and it seems doing this can only cause Bad Things like this bug.

I think that function should just be deleted. We should also see if we can delete the code that issues that notification (not sure if anybody else is using it). See this change for how it gets called:
It's possible to spoof SSL/TLS .
49.4 KB View Download
Labels: -Pri-0 -Area-Undefined Pri-1 Area-Internals Mstone-11 SecSeverity-High OS-All
Status: Available

Comment 9 by, Mar 30 2011

Owner: a deleted user
Status: Assigned
I can take this one, but I'll be out of town the next two days and probably won't have time to make much progress on it until Monday.  If someone else wants to tackle it before then, feel free.
Cc: -a deleted user
Monday sounds good. This is a sensitive area and want to leave it in your able hands. It will be bad to break the navigation logic :(

Comment 11 Deleted

Status: Started
Re: comment 6: It's not quite as simple as deleting TabContents::OnDidRedirectProvisionalLoad, unfortunately.

First, it turns out the pre-rendering code relies on that method so that it can swap in a pre-rendered page for the redirect.  Thus, we would have to relocate that code if we deleted the method.  Maybe we could have it listen to the RESOURCE_RECEIVED_REDIRECT notification in ResourceDispatcherHost (linked at the end of comment 6)?

Second, that TabContents method isn't being called directly by the ResourceDispatcherHost logic.  The RDH logic first sends a ResourceMsg_ReceivedRedirect message to the renderer, which winds through a lot of WebKit logic and then sends it back to the browser as a ViewHostMsg_DidRedirectProvisionalLoad message.  There's lots of places in there that we might filter out the redirect before notifying the pre-rendering logic, including in TabContents::OnDidRedirectProvisionalLoad itself.

Timo, I'm cc'ing you so you have the context for the code review I'm about to send out.
Project Member

Comment 13 by, Apr 6 2011

The following revision refers to this bug:

r80639 | | Wed Apr 06 09:35:49 PDT 2011

Changed paths:

Prevent changes to NavigationEntry's URL for a provisional redirect.

BUG= 77786 
TEST=Visit a page that redirects on reload, then stop before it finishes.

Review URL:
spoofing don't work on google chrome 11.0.696.34 
Status: Fixed
I just tested and the bug is still present in 11.0.696.34.  It's fixed in r80639, which hasn't been deployed yet.
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: WillMerge
Awesome Charlie, 1 down.
We'll need to merge to m11.
when the reward-panel will discuss about my reward? :)

Comment 19 Deleted

@jconsultant.chancel: please be patient. The reward-panel will review the full content of this bug report, and may be disappointed if they see impatience.

The bug got fixed just recently, so I'd expect the reward-panel to review the bug in their next batch of reward reviews. That will likely occur within the next week.
Labels: reward-topanel
sorry for my impatience.
Status: FixUnreleased
Merged to M11 at: Committed revision 80690
Project Member

Comment 24 by, Apr 6 2011

The following revision refers to this bug:

r80690 | | Wed Apr 06 13:56:55 PDT 2011

Changed paths:

Merge 80639 - Prevent changes to NavigationEntry's URL for a provisional redirect.BUG=77786TEST=Visit a page that redirects on reload, then stop before it finishes.Review URL:
Review URL:
Fixed in 11.0.696.43 beta
Labels: -SecSeverity-High -reward-topanel SecSeverity-Medium reward-500 reward-unpaid
Thanks Jordi, I agree this is Medium as per your earlier comment, due to the level of use interaction.
The panel doesn't always reward for Medium bugs, but in this case we're provisionally rewarding $500 as we're happy to be with less spoofs.

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.
thank you very much for this reward.
Labels: CVE-2011-1452
Have you an idea of the release date?
Hopefully within a week... the predictable 6-week release schedules rock :D
I think i can reproduce this without user interaction or with just minimal interaction like juste one click. if it's the case this vulnerability is high?
this vulnerability is high , i can reproduce this without user interaction ...

New Testcase =>
or HTTP://
Hard to say. The first time I hit the URL, I go straight to twitter but it behaves more interestingly if I again open your URL in a new tab a 2nd time.
The test case will redirect half the time to twitter ,please try 2 times , and if the 1frst or the 2nd time the spoofing is well , this is a high spoofing.

I go coded a better testcase.
Test it !

SecSeverity high?
174 bytes View Download
481 bytes View Download
481 bytes View Download
Can you host the latest and greatest at some easily clickable URL?
do you want this ? => Chrome/googlechrome%20location%20spoofing/564vf6d4gdf64/

We're all getting different results. Perhaps there's a weird timing component to this? Given that the fix is going out really soon and the release notes are already written, I'll just leave them as is.

Now the fix is released , i think i can write a small blog-post without PoC.
let me know if you want delete of my blog post (without PoC).
Heya Jordi -- feel free to release the PoC as well. The fix has been out for several days now, so autoupdate should have taken care of matters well enough.

Also, I've started the payout process, in case you were thinking of asking :)
Labels: -reward-unpaid
Invoice finalized; payment is in e-payment system; it can take a couple of weeks.

Comment 44 Deleted

Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Project Member

Comment 48 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 49 by, Mar 10 2013

Labels: -Type-Security -Area-Internals -Mstone-11 -SecSeverity-Medium -SecImpacts-Stable Security-Severity-Medium Cr-Internals Security-Impact-Stable M-11 Type-Bug-Security
Project Member

Comment 50 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 51 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 52 by, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Project Member

Comment 53 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 54 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
Labels: CVE_description-submitted

Sign in to add a comment