Chrome resubmits user data in iframes without prompting, potentially over unsecure WiFi without permission
Reported by
predec...@gmail.com,
Aug 16 2016
|
||||||||||||||||||
Issue descriptionVULNERABILITY 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.
,
Aug 16 2016
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?
,
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
,
Aug 17 2016
Oops....Sorry, I accidentally marked it as "verified".. Thanks for catching this. bug status is corrected.
,
Aug 17 2016
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?
,
Aug 19 2016
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.
,
Aug 19 2016
+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.
,
Aug 19 2016
A screen capture is attached - jialiul is correct about needing to open index.php, not iframe.php
,
Aug 22 2016
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.
,
Aug 22 2016
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.
,
Aug 22 2016
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.
,
Aug 23 2016
Assigning this to MTV as it requires hosting of .php files. MTV@ Could any one from MTV please look into this issue. Thanks,
,
Aug 30 2016
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
,
Sep 6 2016
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.
,
Sep 6 2016
+kavvaru@, could you assign this to a specific MTV TE to speed it up? Thanks!
,
Jan 19 2017
CC'ing pbommana from MTV team. Prudhvi, Request you to please take a look into it. Thanks.!
,
Jan 19 2017
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.
,
Jan 20 2017
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.
,
Jan 20 2017
,
Jan 20 2017
pbommana, why did you add the iframe component back? Form resubmission is a browser feature, not an iframe feature; see Comment 5.
,
Jan 25 2017
@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.
,
Aug 31 2017
,
Sep 3
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
,
Oct 8
This code hasn't been touched substantively since July 2013. avi@, can you take a peek?
,
Oct 9
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 |
||||||||||||||||||
Comment 1 by predec...@gmail.com
, Aug 16 2016