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

Issue 638084 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Chrome resubmits user data in iframes without prompting, potentially over unsecure WiFi without permission

Reported by predec...@gmail.com, Aug 16 2016

Issue description

VULNERABILITY DETAILS
If you submit a form which is in an iframe then close and reopen the containing tab such as by relaunching Chrome with tabs set to remember where you left off, 
the form will get resubmitted without prompting.  This can be a security issue if it was originally submitted on a trusted network but now is being resubmitted over unprotected WiFi for example because the data will be sent without the user's awareness or permission.  If this occurs without an iframe, Chrome will correctly prompt the user first but not when it's in an iframe.

VERSION
Chrome Version: [52.0.2743.116 m] + [stable]
Operating System: [Windows 10 Professional 64 bit version 1511]

REPRODUCTION CASE
Please see the attached set of files and description above to reproduce.  It could be in any language, but PHP was used for this example.
 
iframesecurity.zip
907 bytes Download

Comment 1 by predec...@gmail.com, Aug 16 2016

Comparing this behavior to other browsers, none of the following have this behavior: Firefox, Safari on iPhone, Edge, IE11
Cc: jialiul@chromium.org
Components: Blink>HTML>IFrame
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Pri-2 Type-Bug
Owner: dominicc@chromium.org
Status: Verified (was: Unconfirmed)
Thanks for reporting, predecess@! 
I verified that form did get resubmitted if it is inside an iframe. 

dominicc@, could you take a look at this bug? 

Comment 3 by predec...@gmail.com, Aug 17 2016

I saw this is marked as closed - what does that mean?  A fix has been committed?  It won't be addressed?  It's on the roadmap?  Thanks
Status: Assigned (was: Verified)
Oops....Sorry, I accidentally marked it as "verified".. Thanks for catching this. bug status is corrected. 
Cc: dominicc@chromium.org
Components: -Blink>HTML>IFrame UI>Browser>Navigation
Labels: Needs-Bisect
Owner: ----
Status: Untriaged (was: Assigned)
Summary: Chrome resubmits user data in iframes without prompting, potentially over unsecure WiFi without permission (was: Chrome resubmits user data without prompting, potentially over unsecure WiFi without permission)
I think repost form warnings are actually handled by browser, eg chrome/browser/repost_form_warning_controller.*

Let me know if I can help.

Can someone bisect this and see if this is a regression?
Labels: Needs-Feedback
Tested the issue on Windows 7 using latest stable 52.0.2743.116, canary 54.0.0.2832.2 with below steps:

1.Opened iframe.php code as html file in chrome.
2.Given first name, last name, address values and submitted the form.
3.Checked 'continue where you left off' radio button in chrome://settings.
4.Relaunched the chrome.
5.Observed that previously opened tabs reopened and form also is in same behavior before relaunching.
6.Observed the same behavior in firefox.

Please find attached screencast and update if anything missed here in triaging the issue.

predecess@Could you please provide the actual and expected behavior screeencast with chrome version, OS details for further triaging the issue.

Thank you.
638084.mp4
1.3 MB View Download
Cc: ssamanoori@chromium.org
+ssamanoori@, in your repro step, could you try open the index.php instead of frame.php?  This can only be observed if frame.php is in an iframe.  And the index.php file will also highlight when the form is submitted.

Comment 8 by predec...@gmail.com, Aug 19 2016

A screen capture is attached -  jialiul is correct about needing to open index.php, not iframe.php
ScreenCapture_8-19-2016 1.48.00 PM-1.mp4
769 KB View Download
Cc: kavvaru@chromium.org
Unable to reproduce the issue on windows 7 and 10 using chrome version 52.0.2743.116 with the below steps.

1. Created the html file with the code from index.php
2.Opened the index.html file on chrome
3.Observed the code is displayed inside the frame.the same file opened fine on Firefox.

Please find the attached screen cast and confirm if anything missed in triaging the issue.If possible please provide us the html file to triage the issue from test team end.
638084.mp4
1016 KB View Download
I think you're misunderstanding the issue.  @jialiul appears to have understood it and could reproduce - maybe you can reach out directly?  Please see my screencast again in case that helps.  You cannot change the code to .html from .php - simply use the provided files and watch the screencast I attached.
kavvaru@, could you find somewhere to host the original index.php and frame.php  pocs and give it a try?  And you need to actually submit the form to reproduce the problem. Here is the right step:
1. host index.php and frame.php at let's say foo.com
2. open http://foo.com/index.php
3. fill out the form inside the iframe with whatever you want, submit the form, and look for the submission timestamp (highlighted)
4. close the tab, and reopen it, look for the submission timestamp (highlighted)
5. Notice that the timestamp changed, which suggests a resubmission.  And no warning shown.
Labels: -Needs-Feedback TE-NeedsTriageFromMTV
Assigning this to MTV as it requires hosting of .php files.

MTV@ Could any one from MTV please look into this issue.

Thanks,
Just checking in on this bug. Jialiul@chromium has already confirmed replication and the screen share on comment #8 shows the issue in action. Thanks
Any update?  Btw, this doesn't need to be done with PHP - it could be done with any server-side scripting language that the team normally uses.  
+kavvaru@, could you assign this to a specific MTV TE to speed it up?  Thanks! 
Cc: pbomm...@chromium.org
CC'ing pbommana from MTV team.

Prudhvi, Request you to please take a look into it.

Thanks.!
Cc: -pbomm...@chromium.org
Labels: -TE-NeedsTriageFromMTV M-55 OS-Linux OS-Mac OS-Windows
Owner: pbomm...@chromium.org
Status: Assigned (was: Untriaged)
Able to reproduce the issue on latest Chrome Stable i.e., 55.0.2883.87 on Windows 7,10, Mac and Linux. 

Working on bisect will update soon.

 
Cc: pbomm...@chromium.org
Components: Blink>HTML>IFrame
Labels: -M-55 -Needs-Bisect M-58
Owner: ----
Status: Available (was: Assigned)
I don't think this ever worked in Chrome I checked the behavior as old as Chrome version 43.0.2357.134 still see the issue as comments#8 and 11. 

I am marking the bug as Available, jialiul@ can you please take it from here please.
Labels: Needs-triage-Mobile
Components: -Blink>HTML>IFrame
pbommana, why did you add the iframe component back? Form resubmission is a browser feature, not an iframe feature; see Comment 5.
Cc: msrchandra@chromium.org
Labels: Needs-Feedback
@jialiul -- Could you please re-check on Latest Stable mentioned below and provide us the latest behavior, which would help us to triage the issue further.

As mentioned in Comment 7 & 8, tested the issue on Latest Stable# 55.0.2883.87 (Windows & Linux 14.04), #55.0.2883.95 (Mac), # 55.0.2883.91 (Android).
Navigated to index.php and observed the following text in iframe, "It may have been moved or deleted"
Attaching screen shot for Linux and Android respectively.

Just to update the behavior regarding the added 'Needs-triage-Mobile' label.

The behavior of issue is same as on Desktop, seeing the same text in iframe, "It may have been moved or deleted".

Android Stable# 55.0.2883.91
Devices Tested ::
Mobile -- Nexus 6P / Android 7.1.1 / Build# NMF26X
Tablet -- Galaxy Tab S2 (SM-T815Y) / Android 6.0.1 / Build# MMB29K.

Could some one please look into the issue as iframes has been deprecated in the latest stable build of Chrome.

Thank You.

638084_Desktop.png
43.5 KB View Download
638084_Android.png
190 KB View Download
Labels: -Needs-triage-Mobile
Project Member

Comment 23 by sheriffbot@chromium.org, Sep 3

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-Recharge-Cold -Needs-Feedback -M-58 Target-72 M-72
Owner: a...@chromium.org
Status: Assigned (was: Untriaged)
This code hasn't been touched substantively since July 2013. avi@, can you take a peek?
Cc: nasko@chromium.org clamy@chromium.org
This code has actually changed quite a bit since 2013. The call ultimately comes from NavigationControllerImpl::Reload():

  if (g_check_for_repost && check_for_repost &&
      entry->GetHasPostData()) {
    // ...
    delegate_->ActivateAndShowRepostFormWarningDialog();
  }

Did Plz change this? Are we still only prompting for top-level frames?

Sign in to add a comment