User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20170125094131 Steps to reproduce: I was visiting a forum which has an embedded (iframe) login, and was flagged as insecure by FF. However, after doing a bit of digging, it seems secure and therefore incorrectly marked by the check. 1. Navigate to a page with a HTTPS login within an iframe, such as http://forhonor.ubisoft.com/game/en-US/home/index.aspx. 2. Left click on "Sign in" 3. Right click on Email field, and choose This Frame > Show Only This Frame 4. Note the login widget as displayed is regarded as fully secure (green padlock). Using Devtools Inspector confirmed no HTTP:// links within the iframe. Actual results: Insecure icon and warning was displayed for site. Expected results: Insecure icon and warning should not be displayed for site.
Has STR: --- → yes
OS: Unspecified → Windows 10
Hardware: Unspecified → x86
:MattN, what do you think? Is it by design?
Password fields present on an insecure (http://) iframe. This is a security risk that allows user login credentials to be stolen.[Learn More] https://developer.mozilla.org/docs/Web/Security/Insecure_passwords?utm_source=mozilla&utm_medium=firefox-console-errors&utm_campaign=default
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
Sorry, but I do not understand the rationale for closing this bug? The framing page is HTTP, but the iframe is entirely served on HTTPS and which when resolved separately FF marks as secure. The form submit also occurs as HTTPS according to DevTools. I did read through that page (and a couple of others) before submitting the bug and it seems to meet all the criteria for being marked as secure? (I have also read the etiquette page, so I accept the ruling, just trying to understand)
(In reply to BZilla from comment #3) > Sorry, but I do not understand the rationale for closing this bug? > > The framing page is HTTP, but the iframe is entirely served on HTTPS and > which when resolved separately FF marks as secure. The form submit also > occurs as HTTPS according to DevTools. > > I did read through that page (and a couple of others) before submitting the > bug and it seems to meet all the criteria for being marked as secure? > > (I have also read the etiquette page, so I accept the ruling, just trying to > understand) I am sorry if it is not enough to answer your questions and therefore the abrupt close. If the source of iframe is an http, it can be tampered with providing another iframe address (website) via https. "Web Console Messages Serving the login form over HTTP: Even if the form action is an HTTPS URL, the user's login form is not protected because an attacker can modify the page received by the user (for example, attackers can change the form destination to post the sensitive data to a server that they control, or they can insert a keylogging script that swipes their password as they type it). The security tab of the Web Console will warn developers and users about the security issue:" has also provided in the MDN article.
Thank you for providing additional clarification, it makes sense. IMHO, the page reads that a login form is discrete and therefore evaluated in isolation regardless of whether it is on a secure/insecure framing page or a secure/insecure child entity. Please ask that the MDN team to reword that section? Something along the lines of "For sensitive fields contained within iframes, both the security of the framing page and the iframe are evaluated".
(In reply to BZilla from comment #5) > Please ask that the MDN team to reword that section? > > Something along the lines of "For sensitive fields contained within iframes, > both the security of the framing page and the iframe are evaluated". Use the https://bugzilla.mozilla.org/form.doc to ask. I found it from https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Report_a_problem.
You need to log in before you can comment on or make changes to this bug.