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

Issue 49964 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Security
M-5

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Security: window.history.replaceState fails to enforce domain security

Reported by miketa...@gmail.com, Jul 22 2010

Issue description

The HTML5 spec states, as part of the algorithm for window.history.replaceState:

Compare the resulting absolute URL to the document's address. If any part of these two URLs differ other than the <path>, <query>, and <fragment> components, then raise a SECURITY_ERR exception and abort these steps.

In fact, chromium follows this, throwing the following error:

Error: SECURITY_ERR: DOM Exception 18

However, if the page has a `<base>` tag, with an href set to any arbitrary domain, window.history.replaceState is allowed to change document.location to that arbitary domain, and is updated in the URL bar.

The attached usecase should make it obvious why this is a huge security bug--you can spoof any site *including* the URL.

I can reproduce this in Chromium/Mac 6.0.469.0 (52652), as well as Chrome/Mac 6.0.466.4 dev and Chrome/Mac 5.0.375.99 stable.

Steps to reproduce:

1) Open fakelogin.html either locally or at http://miketaylr.com/test/h4x/fakelogin.html
2) Observe URL or document.location
3) Click the 'Apply Hacks' button in the top bar
4) Observe the URL changing to Gmail's login path, including base domain

5) Enter your Gmail login information and get pwned (don't really do this :P)

It should be noted that this is not possible in the builds of Gecko that support window.history.replaceState, so Chromium/Chrome is the only one vulnerable here.
 
fakelogin.html
14.7 KB View Download

Comment 1 by miketa...@gmail.com, Jul 22 2010

Also, it should be noted that if you do a view-source on the test document after applying the replaceState, it brings up the Gmail login page source--since apparently it performs an HTTP request of document.location.

Comment 2 by jsc...@chromium.org, Jul 22 2010

Labels: -Pri-0 -Area-Undefined Pri-2 Area-WebKit SecSeverity-Medium Mstone-6
I confirmed in stable, trunk and Safari. Seems like this might be a dupe of issue 41435, but the trick with the base tag ups the severity. Taking a look now.

Comment 3 by jsc...@chromium.org, Jul 22 2010

Okay, it's totally unrelated to issue 41435. However, both bugs are in the same place, so I'm just going to knock them out at the same time. I can probably get fixes on both in today.
Labels: -Mstone-6 Mstone-5
Status: Assigned

Comment 5 by jsc...@chromium.org, Jul 23 2010

Status: WillMerge
Fix landed upstream as: http://trac.webkit.org/changeset/63925

Comment 6 by miketa...@gmail.com, Jul 23 2010

Having had more time to play with this, I've found that window.history.pushState({}, "", "/accounts/ServiceLogin?service=mail") produces the same effect.

Does the current change fix this as well? Should it be its own ticket?

Comment 7 by jsc...@chromium.org, Jul 23 2010

Thanks Mike, but the second case is effectively the same as the first. Relative URLs resolve against the current base URL. By setting the base element you're overriding the current base URL.

Comment 8 by jsc...@chromium.org, Jul 23 2010

Labels: -SecSeverity-Medium SecSeverity-High
Whoa, Justin did you just fix that in 5hrs? :)

URL bar spoofs are treated as SecSeverity-High; tag updated.
Thanks for moving so fast on this one. The more I think about it, the more I'm terrified--considering the amount of market share this could be used against.

Nice work.
Labels: reward-1000 reward-unpaid
@miketaylr: aside from the fast fix, there is more good news :) You've provisionally qualified for a $1000 Chromium Security Reward. As per our recent blog post (http://blog.chromium.org/2010/07/celebrating-six-months-of-chromium.html), we are increasing the reward value above the base $500 because of the very high quality of your report.

In terms of release timeframes, we have a patch release going out next week and this fix will make the next patch after that.
yay! :D
Had to reland to fix a functional regression: http://trac.webkit.org/changeset/64077

We'll let it hit dev channel and then roll into the next stable update.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=55077 

------------------------------------------------------------------------
r55077 | inferno@chromium.org | 2010-08-05 09:45:32 -0700 (Thu, 05 Aug 2010) | 29 lines
Changed paths:
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/472/LayoutTests/fast/loader/stateobjects/replacestate-base-illegal-expected.txt
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/472/LayoutTests/fast/loader/stateobjects/replacestate-base-illegal.html
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/472/LayoutTests/fast/loader/stateobjects/replacestate-base-legal-expected.txt
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/472/LayoutTests/fast/loader/stateobjects/replacestate-base-legal.html
   A http://src.chromium.org/viewvc/chrome/branches/WebKit/472/LayoutTests/fast/loader/stateobjects/resources/replacestate-base-pass.html
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/page/History.cpp?r1=55077&r2=55076

Merge 64077 - 2010-07-26  Justin Schuh  <jschuh@chromium.org>

        Reviewed by Darin Fisher.

        Check history state against origin before setting
        https://bugs.webkit.org/show_bug.cgi?id=42858

        Tests: fast/loader/stateobjects/replacestate-base-illegal.html
               fast/loader/stateobjects/replacestate-base-legal.html

        * page/History.cpp:
        (WebCore::History::urlForState):
        (WebCore::History::stateObjectAdded):
2010-07-26  Justin Schuh  <jschuh@chromium.org>

        Reviewed by Darin Fisher.

        Check history state when base URL is changed
        https://bugs.webkit.org/show_bug.cgi?id=42858

        * fast/loader/stateobjects/replacestate-base-illegal-expected.txt: Added.
        * fast/loader/stateobjects/replacestate-base-illegal.html: Added.
        * fast/loader/stateobjects/replacestate-base-legal-expected.txt: Added.
        * fast/loader/stateobjects/replacestate-base-legal.html: Added.
        * fast/loader/stateobjects/resources/replacestate-base-pass.html: Added.

BUG= 49964 

Review URL: http://codereview.chromium.org/3017060
------------------------------------------------------------------------

Status: FixUnreleased
This was merged to 375:

http://src.chromium.org/viewvc/chrome?view=rev&revision=55467

Merge 64077 - 2010-07-26  Justin Schuh  <jschuh@chromium.org>

        Reviewed by Darin Fisher.

        Check history state against origin before setting
        https://bugs.webkit.org/show_bug.cgi?id=42858

        Tests: fast/loader/stateobjects/replacestate-base-illegal.html
               fast/loader/stateobjects/replacestate-base-legal.html

        * page/History.cpp:
        (WebCore::History::urlForState):
        (WebCore::History::stateObjectAdded):
2010-07-26  Justin Schuh  <jschuh@chromium.org>

        Reviewed by Darin Fisher.

        Check history state when base URL is changed
        https://bugs.webkit.org/show_bug.cgi?id=42858

        * fast/loader/stateobjects/replacestate-base-illegal-expected.txt: Added.
        * fast/loader/stateobjects/replacestate-base-illegal.html: Added.
        * fast/loader/stateobjects/replacestate-base-legal-expected.txt: Added.
        * fast/loader/stateobjects/replacestate-base-legal.html: Added.
        * fast/loader/stateobjects/resources/replacestate-base-pass.html: Added.


Review URL: http://codereview.chromium.org/3106001
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
The URL doesn't change anymore. Verified in 5.0.375.127 (Official Build 55887).
Works fine with Google Chrome 5.0.375.127 (Official Build 55887) on Win XP and Linux Ubuntu 9.04
I checked it on Mac :)
Heya Mike -- the fix is now live for all our users. Thanks for your help.
Since this is your first reward with us, please e-mail cevans@chromium.org for details on how to collect!
Hey, that's great news! Many thanks to all that helped get this fixed and for making the web a safer place. :)
Labels: -reward-unpaid
Payment is in the electronic system.... keep an eye out for arrival since it's your first payment :) May take a few weeks. Unfortunately, banks are not as fast as the Chrome Security Team.

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

Comment 29 by bugdroid1@chromium.org, 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 30 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -SecSeverity-High -Mstone-5 -Type-Security -SecImpacts-Stable Cr-Content M-5 Security-Impact-Stable Type-Bug-Security Security-Severity-High
Project Member

Comment 31 by bugdroid1@chromium.org, Mar 13 2013

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

Comment 32 by bugdroid1@chromium.org, Mar 21 2013

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

Comment 33 by bugdroid1@chromium.org, Mar 21 2013

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

Comment 34 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 35 by sheriffbot@chromium.org, Oct 1 2016

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
Project Member

Comment 36 by sheriffbot@chromium.org, Oct 2 2016

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
Labels: allpublic

Sign in to add a comment