Closed Bug 1486749 Opened 6 years ago Closed 5 years ago

No warning in the address bar for login form with HTTP action on HTTPS page

Categories

(Firefox :: Security, defect)

61 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1122237

People

(Reporter: u534134, Unassigned)

References

(Blocks 1 open bug, )

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180807170231

Steps to reproduce:

opened page https://www.fastweb.it/servizi/fastmail/?header-portale=link-mail&from=home that seems to be secure from Firefox, insecure from Chrome.

Firefox alert the page is not completely safe only if you click on the password field.
Should be showed not secure as Chrome not just only when password field is clicked.


Actual results:


Firefox alert the page is not completely safe only if you click on the password field.
Should be showed not secure as Chrome not just only when password field is clicked.


Expected results:

The SSL symbol near the address bar should have a warning of not full secure content in that page.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
20180827100129

HTTPS page, all resources loaded over HTTPS. Form action is HTTP, however.

:MarcoM, you marked bug 1193338 as fixed. Do you know how this situation is supposed to be handled?
Blocks: 1217142
Has STR: --- → yes
Component: Untriaged → Address Bar
Flags: needinfo?(mmucci)
Summary: No mixed content warning → No warning in the address bar for login form with HTTP action on HTTPS page
Hello. Sorry, I don't have any information on this bug.  I have forwarded your request to the triage owner who may be able to help.
Flags: needinfo?(mmucci) → needinfo?(mak77)
Component: Address Bar → Security
Flags: needinfo?(mak77) → needinfo?(tanvi)
Looks like a bug since form action does equal an http link:
<form class="fastmail" name="formLogin" target="_top" action="http://fastmail.fastwebnet.it:80/cp/ps/Main/login/Authenticate?l=it" method="post" onsubmit="return fastwebmailLogin(this);">

We can't detect if an action is a javascript function, but we should be able to detect if it explicitly is an http link.  I'm not sure if we already check for this (and this is a bug) or if this is an enhancement.

I'm also not sure who to redirect this bug to.

2019-03-06

This bug is part of a group of bugs which have had an open needinfo for at least 12 weeks.

The request for information has not been answered, and we can't move forward on the bug so we are closing it.

If the defect is still present, please reopen this bug with an updated report.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE

Reopening since this is still a bug/enhancement. When the insecure password warning is present because of an http form action on the password field, the control center still shows a fully green lock. Should we degrade the control center UI in this case? Or leave it as is - the page is fully secure, but submitting your password is not.

Matt or Johann - do you have thoughts?

Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(tanvi) → needinfo?(MattN+bmo)
Resolution: INCOMPLETE → ---

Personally I think the current behaviour is fine since the user may not be interacting with the "insecure" form so we may be warning them with no clear reason. Once they focus the login field they would see the warning which is good. I think our console warning also happens on load so web developers would know in advance to fix it.

Flags: needinfo?(MattN+bmo)

On my opinion seems to be a browser defect. This is not so good for customer, people like me who trust Firefox.
You will have the final choice but i think it's not correct show a page with a green padlock when no all elements on the page (elements user can interact with) are not secure. Also for smaller web developer... no all see the web-developer console. I reported with time security issue on bank websites, phone company etc... will be not better if the browser show everything is green.

Seems to be a bug from user side also because other browser alert the page is not fully secure... Firefox will hide this in some way until a user doesn't click on the password filed.

The final decision will be yours. Thanks anyway for consider again this.
After the IDN punny code now seems also Firefox will not alert on a page where not all elements are secure. Looks like to be not a nice step to me. Not a good security step... will have maybe less developer that will see issues on pages if they want use a different browser.

Why show a green padlock when not all elements in a page are secure?
Is better show a not green padlock because there are a JPG insecure image and not show mixed content warning if the login filed is not secuire?

(In reply to Marco from comment #7)

Seems to be a bug from user side also because other browser alert the page is not fully secure... Firefox will hide this in some way until a user doesn't click on the password filed.

I would argue that a contextual popup right where the user is interacting with the page is less hidden than the address bar.

The final decision will be yours. Thanks anyway for consider again this.
After the IDN punny code now seems also Firefox will not alert on a page where not all elements are secure. Looks like to be not a nice step to me. Not a good security step... will have maybe less developer that will see issues on pages if they want use a different browser.

Why show a green padlock when not all elements in a page are secure?
Is better show a not green padlock because there are a JPG insecure image and not show mixed content warning if the login filed is not secuire?

Please re-read comment 6… the issue is that there isn't a security problem if the user isn't actually using the form.

Also, keep in mind that the action attribute's value doesn't actually mean that data will go to path specified there… the attribute value can change at any time and the site could instead submit data with fetch/XHR.

I agree with Matt but I would also say that I don't particularly care either way, this sort of behavior is extremely rare last time I checked (0.01% of sites well over a year ago) and so this bug would be a P5 at best. We also have the "are you sure you want to send this information" warning.

If a developer and/or user doesn't notice both of these warnings I don't think a broken lock in the URL bar will do the trick.

In any case this is a dupe of bug 1122237.

Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.