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

Issue 88337 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jul 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

The beforeload event allows tracking URI changes in a frame

Reported by juhon...@gmail.com, Jul 3 2011

Issue description

VULNERABILITY DETAILS
The beforeload event allows a website to track URI changes that happen inside a frame. By abusing this property, an attacker could gain access to sensitive information and security tokens, enabling further CSRF-style attacks.

VERSION
Chrome Version: 14.0.803.0 dev
Operating System: Ubuntu 10.04 LTS

REPRODUCTION CASE
The code below opens a Google redirection page in an iframe. The onbeforeload event attribute is used to detect the URL changes.

<iframe
	src="http://ssl.gstatic.com/chrome/webstore/html/bounce.html#continue=https%3A%2F%2Fchrome.google.com%2Fwebstore%2F"
	onbeforeload="alert('Now opening ' + event.url)">
</iframe>
 
Cc: abarth@chromium.org
Labels: -Pri-0 -Area-Undefined Pri-2 Area-WebKit SecSeverity-Low OS-All Mstone-13
Owner: security@chromium.org
Status: Available
Summary: The beforeload event allows tracking URI changes in a frame
Looks like this webkit specific feature - http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW9 does not handle 302 redirects and keeps updating event.url when it shouldn't ? Perhaps we should freeze event.url ?

Adam, what do you think is the right approach ?
Ouch.  Yeah, we should only trigger the beforeload event on the original frame load (the one that the attacker knows the URL of).

Comment 3 by juhon...@gmail.com, Jul 10 2011

Low? Shouldn't this be tagged AT LEAST medium severity? A huge number of unsuspecting websites - including my bank - being exposed to CSRF seems pretty serious to me...
Putting CSRF token in the URL is a bad practice in itself. It can get logged at multiple places like your ISP, etc. Anyway, this is low severity as per the chromium severity ratings.

Comment 5 by juhon...@gmail.com, Jul 10 2011

According to the severity guidelines, a security issue is of medium severity if it "can be combined with other vulnerabilities to cause harm" and of high severity if it "lets an attacker read or modify confidential data belonging to other web sites". Both are true for this one.
Labels: -SecSeverity-Low SecSeverity-Medium reward-topanel ReleaseBlock-Stable
Yes, this is a Medium.
It's also very similar to much older bug https://code.google.com/p/chromium/issues/detail?id=32309, which we rated as a Medium.
This may also affect a small number of Google websites.

Comment 8 by juhon...@gmail.com, Jul 10 2011

scarybeasts: it does, I've already found one instance.
Out of interest, can you document that instance here?

Comment 10 by juhon...@gmail.com, Jul 10 2011

<iframe
	src="https://www.google.com/accounts/ServiceLogin?service=writely&passive=1209600&continue=http://docs.google.com/settings"
	onbeforeload="alert(event.url)">
</iframe>

The second alerted URL contains the email address of the currently logged in user, and an 'auth' key, of which I'm not sure what it can be used for.
Am I fixing this bug, or is someone else?
Cc: -abarth@chromium.org
Owner: abarth@chromium.org
Status: Assigned
Adam, it will be awesome if you can please help to fix this.
I know you're busy Adam, but if you could knock this one down, it would be much appreciated. I was going to look at it, but a few video bugs just came in :-/
Technically I should be working on gardening tools, but I'm happy to look at this bug.
What a gentleman :) (There's also evidence of scholarly activity too)
Status: Started
The trick is that it needs to be a client redirect.  Server redirects aren't leaked.
Patch in hand.  Is there no WebKit bug already?  I thought we were supposed to open WebKit bugs as soon as practical.
Looks like filing of the bug fell between the cracks. Oops.
Since we're turning up with a patch, I'm sure there will be no ill will.
Status: ExternalDependency
https://bugs.webkit.org/show_bug.cgi?id=64482
Status: Started
Oh wait, we're not supposed to use ExternalDependency any more.  Is there a status for "go look in the WebKit bug for the current status" ?
Not that I know of. "Started" seems good enough; we take it to mean the assignee is all over it :)

I think Abhishek was using "ExternalDependency" for cases where an Apple engineer took a security bug. Seems reasonable because the timescale there is less under our control.
Cc: japhet@chromium.org
r+ achieved upstream :D

Adam, any thoughts on how risky this one is in terms of a merge? (I will take care of the merge if necessary)
Very safe.  I need to tweak the patch before landing, which I should be able to do tonight.
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: WillMerge
http://trac.webkit.org/changeset/91044
Status: FixUnreleased
Merged to M13: http://trac.webkit.org/changeset/91141
@juhonurm: how would you like to be credited in our release notes?

Comment 29 by juhon...@gmail.com, Jul 16 2011

My real name is Juho Nurminen. Use that, please.
Labels: -reward-topanel reward-500 reward-unpaid
@juhonurm: very interesting bug! Thanks for reporting it. We're happy to offer a provisional $500 Chromium Security Reward for your help.

----
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.
----

Comment 31 by juhon...@gmail.com, Jul 20 2011

Cool. Thanks :)
Labels: CVE-2011-2800
Labels: SecImpacts-Stable
Batch update.
@juhonurm: please e-mail cevans@chromium.org for steps to collect your reward
Labels: -reward-unpaid
Payment in system.

Comment 36 by cdn@chromium.org, May 15 2012

Status: Fixed
Marking old security bugs Fixed.. 
Project Member

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

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

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

Labels: Restrict-View-EditIssue
Project Member

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

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

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

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

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

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

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

Labels: -Cr-Content Cr-Blink
Project Member

Comment 45 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 46 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
Labels: CVE_description-submitted

Sign in to add a comment