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 2 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Sep 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security
M-7

Blocking:
issue 48466

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 48225: Autofill profile (address, perfsonal info) spam without any need of user interaction

Reported by infe...@chromium.org, Jul 3 2010 Project Member

Issue description

Version affected v6 trunk - 6.0.454.0 (51494)

Because of a recent change in autofill behavior, there is no infobar raised to save user profile, address information. As a result, an evil webpage can autosubmit a form using javascript with junk values which get ultimately stored as an autofill entry in the user profile. 

I would definitely wish to get the infobar back, just like currently you use it just for cc data. Or otherwise, we need to make sure there is explicit user interaction required before form data gets stored in the profile. 

Attaching testcase
 
profilespam.gif
24.0 KB View Download
profilespam.html
1.7 KB View Download

Comment 1 by infe...@chromium.org, Jul 3 2010

Labels: Mstone-6

Comment 2 by infe...@chromium.org, Jul 3 2010

Labels: Feature-Autofill

Comment 3 by jhawkins@chromium.org, Jul 6 2010

This feature will not be released as it previously existed.  At the very least, we have to aggregate profile data.  That being said, I don't see how the InfoBar is concerned in the discussion of an evil web page submitting junk data.  In the worst case scenario, an evil web page will fill out one profile with a limited number of fields.  The user will notice this data, open the AF dialog, delete the data and potentially disabled AF.

Any thoughts Jeff?

Comment 4 by infe...@chromium.org, Jul 6 2010

Unfortunately, the attacker can do more harm that just affect one autofill profile. He or she can add infinite number of autofill entries/labels, leaving the user in a really bad situation of only cleaning/deleting the entire chrome user profile as the only cleansing option [as user cannot delete large no of autofill entries like >100 by clicking one by one]. this might also result in browser crash which can leave user's data unsaved.
profilespam.html
1.8 KB View Download
profilespam2.jpg
133 KB View Download

Comment 5 by infe...@chromium.org, Jul 6 2010

typo -> more harm that just -> more harm than just

Comment 6 by infe...@chromium.org, Jul 6 2010

just a fyi, when i ran this code for like 3 min (with 0 in settimeout argument of testcase in comment #4), it crashes the browser. Also, i didn't find an easy way to clean/remove all autofill data. the remove button just clears one entry. the option that works is the pressing of ctrl+a (select all) then then press remove button to clear all, but this might not be easily guessed by many users.

Comment 7 by jhawkins@chromium.org, Jul 6 2010

 Issue 48226  has been merged into this issue.

Comment 8 by jhawkins@chromium.org, Jul 6 2010

The only way I can see to mitigate this is if there were a way to determine how the form is submitted: if the user initiated the action (mouse, keyboard, etc.) then it's fine; otherwise, don't accept the form.  I don't know if this is a possibility though.

Comment 9 by infe...@chromium.org, Jul 6 2010

James, can you try using UserGestureIndicator, that should help.
http://trac.webkit.org/changeset/58872
http://trac.webkit.org/changeset/61941
http://trac.webkit.org/changeset/59462

ccing Chris, Adam, Johnny. They implemented this functionality and it should be in working state for v6 i suppose.

Comment 10 by infe...@chromium.org, Jul 6 2010

Using the user gesture will protect against infinite spam, but still autofill data can be added with user interaction where the user does not know if he or she is submitting form or just clicking a button to do something (where all forms fields except submit button is covered by css overlays). try the testcase attached.
profilespam.html
1.6 KB View Download

Comment 11 by jhawkins@chromium.org, Jul 7 2010

Noted; however, we have to balance security with usability, and one spam profile is worth the value of usability, in my opinion.

Yes, I will look into routing UserGestureIndicator up to AutoFill, thanks.

Comment 12 by infe...@chromium.org, Jul 7 2010

Blockedon: 48466
 Bug 48466  will be tracking the overall security audit progress for autofill.

Comment 13 by lafo...@chromium.org, Jul 7 2010

Labels: OS-All
Cleaning up mstone:6 bugs, default assumption is that bugs w/ no os are os-all

Comment 14 by jeffreyc@chromium.org, Jul 8 2010

I think hooking up UserGestureIndicator would be good. Otherwise I agree that letting the profile data be saved automatically is the right balance of usability and security.  If UserGestureIndicator protects against automated "infinite profile spam", that would only leave manual one-spam-profile-at-a-time which I think is fine.

Comment 15 by infe...@chromium.org, Jul 9 2010

There are two scenarios

1) User fills up legit profile (address data) that gets autosaved in autofill with a click. User does not know his personal info got saved automatically since he/she does not get any visual clue (like a infobar).
2) User goes to a evil site and does a series of clicks on various buttons. considering attacker explicit hides rest of form fields, user does not his know multiple spam profiles (not just one, this depends on how many clicks user did) are added to the autofill. if we had popped up the infobar, that would have made user suspicious and might not use the evil site anymore.

I am fine with UserGestureIndicator. Additionally, just want yu to think if we should use a infobar informing the user in any way that some personal info has got saved in a non-intrusive way. point (1) might be required by privacy folks (+cc jochen for his opinion). I dont want to compromise usability of autofill, so just running the idea through.

note that infobar here i meant just a information bar, and not a yes/no decision.

Comment 16 by jeffreyc@chromium.org, Jul 9 2010

Thanks for the input. We've discussed having an informational infobar to tell the user that their info is being saved, but decided against it to make the feature more usable and seamless. I am comfortable with this because Safari AutoFill also does it automatically.

Note that I'm only talking about non credit card information -- the infobar ALWAYS asks before saving any credit card information.

Comment 17 by jhawkins@chromium.org, Jul 12 2010

Blockedon: -48466

Comment 18 by jhawkins@chromium.org, Jul 15 2010

Status: Started

Comment 19 by jhawkins@chromium.org, Jul 20 2010

WK side landed at r42479.

Comment 20 by infe...@chromium.org, Jul 20 2010

More specifically :) webkit revision number is http://trac.webkit.org/changeset/63786. for webkit bug https://bugs.webkit.org/show_bug.cgi?id=42479.

Comment 21 by dhollowa@chromium.org, Jul 21 2010

Comment 23 by jhawkins@chromium.org, Jul 22 2010

Status: WillMerge

Comment 24 by infe...@chromium.org, Jul 23 2010

verified in 6.0.475.0 (53429) with my previous testcase. Also tried with another testcase of trying to propagate enter key event on the submit button and seeing it work or not ? it didn't.
profilespam2.html
2.2 KB View Download

Comment 25 by bugdro...@gmail.com, Jul 26 2010

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

------------------------------------------------------------------------
r53685 | inferno@chromium.org | 2010-07-26 14:19:47 -0700 (Mon, 26 Jul 2010) | 33 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/html/HTMLFormElement.cpp?r1=53685&r2=53684
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/html/HTMLFormElement.h?r1=53685&r2=53684
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebKit/chromium/public/WebFormElement.h?r1=53685&r2=53684
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebKit/chromium/src/WebFormElement.cpp?r1=53685&r2=53684

Merge 63786 - 2010-07-16  James Hawkins  <jhawkins@chromium.org>

        Reviewed by Darin Fisher.

        [Chromium] Implement WebFormElement::wasUserSubmitted(). This is used to
        verify that the user submitted the form instead of JS when saving form
        data in AutoFill.
        https://bugs.webkit.org/show_bug.cgi?id=42479

        * public/WebFormElement.h:
        * src/WebFormElement.cpp:
        (WebKit::WebFormElement::wasUserSubmitted):
2010-07-16  James Hawkins  <jhawkins@chromium.org>

        Reviewed by Darin Fisher.

        Expose the form submission trigger on the HTMLFormElement object. This
        is used to verify that the user submitted the form instead of JS when
        saving form data in Chrome AutoFill.
        https://bugs.webkit.org/show_bug.cgi?id=42479

        No new tests as this is only used by the Chromium WebKit API.

        * html/HTMLFormElement.cpp:
        (WebCore::HTMLFormElement::HTMLFormElement):
        (WebCore::HTMLFormElement::submit):
        (WebCore::HTMLFormElement::reset):
        (WebCore::HTMLFormElement::submissionTrigger):
        * html/HTMLFormElement.h:

BUG= 48225 

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

Comment 27 by infe...@chromium.org, Jul 26 2010

Status: Fixed

Comment 28 by scarybea...@gmail.com, Aug 25 2010

Labels: -Restrict-View-SecurityTeam

Comment 29 by infe...@chromium.org, Aug 31 2010

Labels: -Mstone-6 Mstone-7
Status: Assigned
Reopening pending the issue that came up in bug http://code.google.com/p/chromium/issues/detail?id=52940. Also, only changes to 472 are reverted. Trunk needed to be fixed.

Comment 31 by bugdro...@gmail.com, Aug 31 2010

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

------------------------------------------------------------------------
r58049 | inferno@chromium.org | 2010-08-31 12:42:34 -0700 (Tue, 31 Aug 2010) | 35 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/html/HTMLFormElement.cpp?r1=58049&r2=58048
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/html/HTMLFormElement.h?r1=58049&r2=58048
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebKit/chromium/public/WebFormElement.h?r1=58049&r2=58048
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebKit/chromium/src/WebFormElement.cpp?r1=58049&r2=58048

Revert 53685 - Merge 63786 - 2010-07-16  James Hawkins  <jhawkins@chromium.org>

        Reviewed by Darin Fisher.

        [Chromium] Implement WebFormElement::wasUserSubmitted(). This is used to
        verify that the user submitted the form instead of JS when saving form
        data in AutoFill.
        https://bugs.webkit.org/show_bug.cgi?id=42479

        * public/WebFormElement.h:
        * src/WebFormElement.cpp:
        (WebKit::WebFormElement::wasUserSubmitted):
2010-07-16  James Hawkins  <jhawkins@chromium.org>

        Reviewed by Darin Fisher.

        Expose the form submission trigger on the HTMLFormElement object. This
        is used to verify that the user submitted the form instead of JS when
        saving form data in Chrome AutoFill.
        https://bugs.webkit.org/show_bug.cgi?id=42479

        No new tests as this is only used by the Chromium WebKit API.

        * html/HTMLFormElement.cpp:
        (WebCore::HTMLFormElement::HTMLFormElement):
        (WebCore::HTMLFormElement::submit):
        (WebCore::HTMLFormElement::reset):
        (WebCore::HTMLFormElement::submissionTrigger):
        * html/HTMLFormElement.h:

BUG= 48225 , 52940 

Review URL: http://codereview.chromium.org/2881040

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

Comment 32 by bugdro...@gmail.com, Aug 31 2010

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

------------------------------------------------------------------------
r58052 | inferno@chromium.org | 2010-08-31 12:54:02 -0700 (Tue, 31 Aug 2010) | 38 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/html/HTMLFormElement.cpp?r1=58052&r2=58051
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebCore/html/HTMLFormElement.h?r1=58052&r2=58051
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebKit/chromium/public/WebFormElement.h?r1=58052&r2=58051
   M http://src.chromium.org/viewvc/chrome/branches/WebKit/472/WebKit/chromium/src/WebFormElement.cpp?r1=58052&r2=58051

Revert 58049 - Revert 53685 - Merge 63786 - 2010-07-16  James Hawkins  <jhawkins@chromium.org>

        Reviewed by Darin Fisher.

        [Chromium] Implement WebFormElement::wasUserSubmitted(). This is used to
        verify that the user submitted the form instead of JS when saving form
        data in AutoFill.
        https://bugs.webkit.org/show_bug.cgi?id=42479

        * public/WebFormElement.h:
        * src/WebFormElement.cpp:
        (WebKit::WebFormElement::wasUserSubmitted):
2010-07-16  James Hawkins  <jhawkins@chromium.org>

        Reviewed by Darin Fisher.

        Expose the form submission trigger on the HTMLFormElement object. This
        is used to verify that the user submitted the form instead of JS when
        saving form data in Chrome AutoFill.
        https://bugs.webkit.org/show_bug.cgi?id=42479

        No new tests as this is only used by the Chromium WebKit API.

        * html/HTMLFormElement.cpp:
        (WebCore::HTMLFormElement::HTMLFormElement):
        (WebCore::HTMLFormElement::submit):
        (WebCore::HTMLFormElement::reset):
        (WebCore::HTMLFormElement::submissionTrigger):
        * html/HTMLFormElement.h:

BUG= 48225 , 52940 

Review URL: http://codereview.chromium.org/2881040

Review URL: http://codereview.chromium.org/3215013

TBR=inferno@chromium.org
Review URL: http://codereview.chromium.org/3279009
------------------------------------------------------------------------

Comment 33 by bugdro...@gmail.com, Aug 31 2010

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

------------------------------------------------------------------------
r58053 | inferno@chromium.org | 2010-08-31 12:55:58 -0700 (Tue, 31 Aug 2010) | 15 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/autofill/autofill_manager.cc?r1=58053&r2=58052
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/autofill/form_structure.cc?r1=58053&r2=58052
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/autofill/form_structure_unittest.cc?r1=58053&r2=58052
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/common/render_messages.h?r1=58053&r2=58052
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/renderer/form_manager.cc?r1=58053&r2=58052
   M http://src.chromium.org/viewvc/chrome/branches/472/src/webkit/glue/form_data.h?r1=58053&r2=58052

Revert 58044 - Revert 53686 - Merge 53350 - AutoFill: Record whether the user initiated the form submission and don't save form data if the form was not user-submitted.

BUG= 48225 , 52940 
TEST=none

Review URL: http://codereview.chromium.org/2842062

TBR=jhawkins@chromium.org
Review URL: http://codereview.chromium.org/3063008

TBR=inferno@chromium.org
Review URL: http://codereview.chromium.org/3251007

TBR=inferno@chromium.org
Review URL: http://codereview.chromium.org/3258008
------------------------------------------------------------------------

Comment 34 by bugdro...@gmail.com, Aug 31 2010

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

------------------------------------------------------------------------
r58054 | inferno@chromium.org | 2010-08-31 13:03:09 -0700 (Tue, 31 Aug 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/browser/autofill/autofill_manager.cc?r1=58054&r2=58053

Remove javascript form submission security check until furthur analysis.

BUG= 48225 

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

Comment 35 by infe...@chromium.org, Sep 3 2010

Labels: Restrict-View-SecurityTeam

Comment 36 by dhollowa@chromium.org, Sep 9 2010

Status: Started

Comment 37 by dhollowa@chromium.org, Sep 10 2010

Status: Fixed
WebKit fix submitted.  Marking this bug fixed, pending WebKit CL landing and roll).

https://bugs.webkit.org/show_bug.cgi?id=45128

Comment 38 by infe...@chromium.org, Sep 10 2010

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: WillMerge
Thanks David. I committed in webkit r67240: <http://trac.webkit.org/changeset/67240>. Will merge to 517 in a day or two after it settles on canary.

Comment 39 by infe...@chromium.org, Sep 17 2010

Status: FixUnreleased
Merged to 517.

Comment 40 by scarybea...@gmail.com, Nov 3 2010

Status: Fixed

Comment 41 by scarybea...@gmail.com, Nov 3 2010

Labels: -Restrict-View-SecurityNotify

Comment 42 by jsc...@chromium.org, Mar 21 2011

Labels: Type-Security

Comment 43 by jsc...@chromium.org, Oct 5 2011

Labels: SecImpacts-Stable
Batch update.

Comment 44 by jsc...@chromium.org, Oct 5 2011

Labels: SecImpacts-None
Batch update.

Comment 45 by jsc...@chromium.org, Jan 30 2012

Labels: -SecImpacts-None
Batch update.

Comment 46 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Blocking: -chromium:48466 chromium:48466
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.

Comment 47 by bugdroid1@chromium.org, Mar 10 2013

Project Member
Labels: -Area-UI -SecSeverity-Medium -Mstone-7 -Feature-Autofill -Type-Security -SecImpacts-Stable Security-Impact-Stable M-7 Security-Severity-Medium Cr-UI Type-Bug-Security Cr-UI-Browser-Autofill

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

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

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

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

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

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

Comment 51 by laforge@google.com, Jul 24 2013

Cc: -jeffreyc@chromium.org

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

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

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

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

Comment 54 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic

Comment 55 by sheriffbot@chromium.org, Jul 29 2018

Project Member
Labels: -Pri-2 Pri-1

Sign in to add a comment