1337338 - When a http form is injected via JavaScript the padlock doesn't change to broken

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[Jonathan Kingston [:jkt] he/him]

STR:

1. Go to: mozilla.com
2. Open the developer console and submit:
let form = document.createElement('form'); form.setAttribute("action","http://example.com"); form.innerHTML = "<input type=\"password\"/>"; document.body.appendChild(form);

The console warns with:
Password fields present in a form with an insecure (http://) form action. This is a security risk that allows user login credentials to be stolen.

However the insecurePassword padlock isn't present in the URL bar like it is for: http://http-dynamic-login.badssl.com/

However going to: http://http-credit-card.badssl.com/ (which currently doesn't break the padlock and changing a text field in the inspector to a password breaks the padlock)

Comment 1

[Jonathan Kingston [:jkt] he/him]

Interestingly this works in a content script in an extension (which was my initial use-case) perhaps there is a race condition causing the padlock not to be broken after load? Even with a setTimeout the extension still works though.

Comment 2

[Daniel Veditz [:dveditz]]

Jonathan: who implemented the UI for this? we should needinfo or assign to that person but it sounds more front-end than backend "DOM Security".

Comment 3

[:Paolo Amadini]

This bug probably needs to be moved to the right front-end component.

Comment 4

[Johann Hofmann [:johannh]]

I think this is Password Manager :)

Comment 5

[Jonathan Kingston [:jkt] he/him]

:MattN asked if the field had an in context warning on the password field... I can confirm that it does. This may reduce the priority.

Comment 6

[Erin Lancaster [:elan]]

Back to P3.

Comment 7

[ExE Boss]

It seems that the extension case has recently regressed¹, as https://addons.mozilla.org/firefox/addon/snap-http-padlocks/ no longer seems to work.

¹ possibly as a result of bug 1310447