Closed Bug 46590 Opened 24 years ago Closed 2 years ago

Warn users at submit time about insecure/HTTP form submissions


(Toolkit :: Form Manager, enhancement)

Not set





(Reporter: ian, Unassigned)



From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m17) Gecko/20000726
BuildID:    2000072608

When you are submitting an insecure form which contains what appears to be a
credit card number (ie, all numbers & spaces, 10-20 numbers unless there is a
standard length) an confirm box should be shown containing something like:

"You appear to be submitting credit card information. This is an insecure
connection, and there is therefore a risk that this information could be
intercepted. It is recommended you cancel.
[Continue] [Cancel - default]"

Reproducible: Always
Steps to Reproduce:
1.Go to website with insecure credit card form
2.insert details. submit

Actual Results:  Form was submitted no problem

Expected Results:  Alert shown warning me I was submitting credit card
informating insecurely.
Triaging rods bug list.
Eric, do you know who is in charge of bringing up security warning dialogs?
Assignee: rods → pollmann
The insecure form submit warning dialog has been implemented and is working in
nearly all cases. If you have a specific URL that is failing, can you please
attach it to this bug report?  Thanks!  (Make sure you're running M17 or a
really recent nightly build to see this feature)
If I understand correctly you are saying that if _any_ information being 
submitted over an insecure form you will get an aleat. Because of the number of 
insecure forms around most people turn these off.

My suggestion would notice a credit card number and alert them if it is being 
transposted insecurely - it would be seperate from the above dialog. It is very 
easy to forget to look for a secure connection, an alert like this would help.

Tested 26/07/2000 build and there were no alerts (I think I disabled them).
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
Severity: normal → enhancement
Summary: [RFE] User should be alerted if submitting credit card details insecurely → [RFE] insecure submit of credit card # should warn user even if insecure submit warning turned off
Updating QA contact.
QA Contact: ckritzer → vladimire
Jogging bug for inclusion in Mozilla 1.0
Perhaps this should be implemented in JavaScript?
This is an RFE, but CC'ing people who have implemented similar things and might
be interested in this suggestion.  (This could be implemented as an extension
like wallet or the psm-glue warning dialog, but would be significantly simpler)
I'm personally against such a thing.  You would be using an heuristic to 
determine if it is a credit card number and are bound to give bogus warnings in 
some cases.  I, as a user, turned off these warnings because I was tired of 
seeing them and now you are throwing them back at me.  If such a thing were 
implemented, at the very least it should be under control of a pref and that 
pref should be off by default.

Furthermore, who's to say what a particular user considers sensitive.  Do we 
want to try to detect social security numbers as well?  What about telephone 
numbers?  Frequent flyer numbers?

(BTW, if you really want to test a field for a credit card number, there is an 
algorithm for determining valid numbers.  So you could improve the heuristic 
considerably.  But I still don't recommend that you do this.)
Of course you would get some bugus warnings, but using the algorithm you 
mentioned should minimize these. Also, the user would be able to disable the 
warning just like they can disable the other warnings. This could be combined 
into the insecure-submit alert box somehow. This feature is designed for people 
who have turned the warnings off, if the warnings were still on then there 
wouldn't be a problem. I say it should be enabled by default.

As for what is sensitive, does it matter? Most people will consider credit card 
numbers sensitive, so it is better than what we have at the moment (ie All or 
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Summary: [RFE] insecure submit of credit card # should warn user even if insecure submit warning turned off → [RFE] insecure submit of credit card # should warn user even if insecure submit warning turned off[form sub]
Summary: [RFE] insecure submit of credit card # should warn user even if insecure submit warning turned off[form sub] → insecure submit of credit card # should warn user even if insecure submit warning turned off[form sub]
See also bug 188285, Phoenix form autocomplete should not store credit card numbers.
I was going to suggest a similar feature, but with more specific criteria.

The feature I want is:
   - Warn if insecurely submitting a 16-digit numbers containing ____
I would then fill in several digits from my VISA card number.
This would eliminate essentially all false positives.
The default would be to match *all* form fields that contain
exactly 16 digits and no alphabetic characters.

The same could be offered for other popular credit card lengths.
There are only a few lengths in use, internationally.

Region packs should be able to add more.  For example, in the US,
a nine-digit number may be a social security number, and if it
contains the lasr (or first) four digits of my SSN, I want to
be warned if I send it unencrypted.

I'm proposing the next release after this one as a milestone;
it's been set to Future since the late 20th century.
The future is now.
Target Milestone: Future → mozilla1.5alpha
Your sugegstion sounds reasonable but please do NOT change the target miletone
of bugs that are not assigned to you.
Target Milestone: mozilla1.5alpha → Future
(In reply to comment #11)
> See also bug 188285, Phoenix form autocomplete should not store credit card
> numbers.

above bug was WONTFIXed in mid-2003
We can do better than matching simply by length. A better test would include verifying the check digit built into the numbers, which uses the Luhn algorithm. As far as I know this has been universally used for at the least past decade. Some information is here:

Assignee: alexsavulov → nobody
QA Contact: vladimire → form-submission
Moving to Form Mananger, since that's most likely where it should be implemented (as part of FM's usual process of watching form submissions).
Component: HTML: Form Submission → Form Manager
Priority: P3 → --
Product: Core → Toolkit
QA Contact: form-submission → form.manager
Target Milestone: Future → ---
Version: Trunk → unspecified
Now that Luhn algorithm checking has been implemented in bug 188285 (which was un-WONTFIXed and recently FIXED), this bug should now be doable by using that to check before submission.
Depends on: 188285
Assignee: nobody → dolske
(clearing assignment of bugs I'm no long planning to work on)
Assignee: dolske → nobody
The insecure form submit warning dialog has been implemented and is working in
nearly all cases. This is not a bug or defect and should be closed as INVALID.
A few more points:

1) "many users will just click the ok  without thinking."
2) If for some strange reason #1 doesn't apply (it should, they are not my words but that of a longstanding community member): Users will see a security warning. They will come to expect that firefox "holds their hand" in security matters and when they do not see any warning they will incorrectly assume this implies security.

This is a very slippery slope. I agree that security is important but the best security is obtained by providing the users the tools or information needed for the security and let the user decided what choice to make. Also, showing this warning ONLY for non-SSL sights is misleading. There have been many security breaches of certificate authorities in the past and sadly it is inevitable there will be future breaches as well. Also the concept of "trust" from a CA is misleading at best. Many CA issue domain verification certificates and these are the most common. This means that even displaying a message "You are submitting a credit card number to, are you sure you trust" can only be misleading at best. The ONLY way to avoid this is for the user to be smart about their browser/computer usage. We can try all day long to write a perfect browser but that will produce an annoying browser that is no more secure than what we have today.
I think fixing bug 188285 made fixing this unnecessary.
Closed: 11 years ago
Resolution: --- → WONTFIX
I don't want to reopen this myself because I'm the original reporter, but rather than saying that bug 188285 makes this unnecessary I think it vindicates the original suggestion. Many of counter points above are about too many false positives or missed sensitive information which apply equally to that bug.

By fixing that bug we have been made this one easier to fix with minimal false positives - i.e. in the rare case that someone does see this warning then there is a very high chance that they are risking the security of their card details. The vast majority of card forms are over SSL, so people won't get used to seeing this warning. Suitable wording and making the safe option the default will help to reduce the 'just click passed the annoying message' problem.
Sorry, I guess I closed this too hastily - not remembering them in form history is not the same as not submitting them insecurely, indeed.
Resolution: WONTFIX → ---
See Also: → 1349681
I suspect this will be wontfix in favour of bug 1349681 and bug 1371149 since it's better to provide the warning before the data is even typed (in the event that the form itself is on an insecure origin).
See Also: → 1371149
Summary: insecure submit of credit card # should warn user even if insecure submit warning turned off[form sub] → Warn users at submit time about insecure/HTTP form submissions

Bugs mentioned by :MattN in Comment 24 are fixed. Web has evolved since this bug was opened, today sites can leak information before or even without submit events.

Closed: 11 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.