63095 - Submitting form with https action from http page brings up a "the information you submit is insecure" dialog

Status: VERIFIED WONTFIX

(Core Graveyard :: Security: UI, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: linux 2000-12-05-08

STEPS TO REPRODUCE:
1) Make sure you have the warning for insecure form submissions turned on.
2) Go to any http:// site that has a form with an https:// action.  The Amazon
login page at
http://www.amazon.com/exec/obidos/flex-sign-in/105-1341200-5430310?opt=a&page=help/ya-sign-in-secure.html&response=order-list&method=POST&return-url=order-list
is a good example.
3) Submit the form.

ACTUAL RESULTS:
The "any information you submit is insecure" dialog pops up.

EXPECTED RESULTS:
Form results sent to https:// url with no warning dialogs.

COMMENTS:
It looks like Mozilla uses the secureness of the page instead of that of the
ACTION attribute to determine whether to pop up the dialog.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note: I also see this in a 2000-12-15 linux CVS build

Comment 2

[Håkan Waara]

Attachment: patch - we showed the dialog if the current page was insecure.

Comment 3

[Boris Zbarsky [:bzbarsky]]

adding keywords, changing bug status to new

Comment 4

[Boris Zbarsky [:bzbarsky]]

over to security

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Looks like incorrect behavior. Over to crypto.

Comment 6

[John Unruh]

*** This bug has been marked as a duplicate of 59499 ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

This is different from bug 59499 in that that one talks about going to an
insecure page while this one talks about submitting an insecure form...

In this case, there is an incorrect dialog saying the submission is insecure
followed by a correct dialog that says you are entering a secure site.  The two
dialogs are created at different places in the code...

Also, this bug has a patch that fixes it and only needs review.  This patch
affects bug 59499 not at all.

I'm reopening this; junruh, could you please explain why it's a duplicate of bug
59499 if you decide to resolve it as duplicate again?  Thanks.

Comment 8

[Ken Knuteson]

Bug 59499 involves any use of JavaScript to submit a secure form.  The page can 
be secure and the form secure, but if the form is submit using JavaScript you 
will get the warning that you are leaving a secure site.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated patch

Comment 10

[Javier Delgadillo]

r=javi on latest patch.

Comment 11

[John G. Myers]

I believe the current behavior is correct.  If the form was obtained insecurely, 
then an attacker could modify it to control what the user later submits over 
http.  Consider an order form, where the attacker passes through the user's 
credit card and billing address, but causes a fixed attacker-specified string to 
be submitted as the shipping address.

Comment 12

[John G. Myers]

More simply, an attacker could change the protocol and domain part of the URL to 
which the form is submitted to point to an https server the attacker controls.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Good point, John.  Marking wontfix based on that.

Comment 14

[John Unruh]

Verified wontfix.

Comment 15

[John Unruh]

Mass changing Security:Crypto to PSM

Comment 16

[John Unruh]

Mass changing Security:Crypto to PSM

Comment 17

[Jesse Ruderman]

See also bug 96556, the warning message for http->https form submission says 
the data is being submitted in "clear text".

Comment 18

[Boris Zbarsky [:bzbarsky]]

*** Bug 115048 has been marked as a duplicate of this bug. ***

Comment 19

[Ramón García Fernández]

Anyway the behaviour of Mozilla is confusing. A different dialog should 
be shown, saying that there is an access to a secure web page from an
insecure one, which is insecure.

I think that the bug should be reopened.

Comment 20

[Ramón García Fernández]

A dialog box saying,

"Verify that the target URL, https://..... is correct"

would be perfect. If the target URL is correct, there is no security problem
with the source page.

Comment 21

[Boris Zbarsky [:bzbarsky]]

That would be insufficient.  See comment 11.

Comment 22

[Ramón García Fernández]

Thanks, in addition the dialog box could post the values posted.

Warning: posting to a secure web site from a secure page.

Check the page https:/.....  and the values :
 var1= ...
 var2= ...

are correct.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Um...  on the average this would make the dialog not fit on a 600x800 screen. 
Forms post a _lot_ of hidden values, typically.

At that point users would simply turn off this warning to avoid getting
screen-sized dialogs when they submit forms.

Comment 24

[Ramón García Fernández]

Anyway, it is important that the warning is not the same as the one shown 
when the target URL is not https. The user should know that Mozilla is not
buggy. :-). 

Comment 25

[Ramón García Fernández]

Replay to comment #23:

The dialog box can be well designed. For example, it can contain a button 
"show form parameters>>" that when you press it it expands the dialog to
showing the list of parameters in a scrolled list.

Comment 26

[John G. Myers]

A dialog with a complicated "show form parameters" button does not strike me as
being well designed.

The ultimate goal of the dialog box is to get the server maintainers to fix
their security.

Comment 27

[Ramón García Fernández]

In replay to comment #26

I think that it is the best thing that you can do for the user.
In addition, you can tell the user that the web page should be
better designed. But it might be difficult of long to get the page
changed. In the meantime, you should help the user.

With the present behaviour, the user sees that the web page works
fine in Internet Explorer and think that it is either a bug in
Mozilla or a web page that requires Internet Explorer. (This is
what my Ph D supervisor thought after he installed Netscape 6.2
at home).

Comment 28

[John G. Myers]

The wording of the dialog box should not imply that the site is even partially
secure.  Nor is it reasonable to expect the user to make such a complicated
security decision.

It might be reasonable to expand the description of the security threat, but
that increases the risk that the user won't read the dialog box at all.

Comment 29

[Ramón García Fernández]

Although you are technically right, such attack requires domain hihacking,
which is very difficult.

The most frequent case is the portal of a service, where after typing a user
and a password the user enters the https secure zone. In cases like this, the
user can fix the problem himself by adding a "s" after http
in the address text box and then type enter to load the page again.

Probably Mozilla should advise the user to do this.

Comment 30

[John Keiser (jkeiser)]

*** Bug 96556 has been marked as a duplicate of this bug. ***

Comment 31

[Boris Zbarsky [:bzbarsky]]

*** Bug 143418 has been marked as a duplicate of this bug. ***

Comment 32

[Boris Zbarsky [:bzbarsky]]

*** Bug 145555 has been marked as a duplicate of this bug. ***