182179 - False unencrypted submit warning when action is javascript submitting a different form

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Rob H]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6

AFAIK the form in question is secure. I don't get warnings with other browsers.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
Unencrypted warning.

Expected Results:  
no warning

Comment 1

[Greg K.]

Rob, your bug report is incomplete. Please supply the steps to reproduce it.

Comment 2

[Rob H]

To reproduce, 

1 go to the supplied URL.
2 type in anything to the username and password fields
3 hit return or the submmit button.

Comment 3

[Stephane Moureau]

Confirmed using 1217.
URL provided was incorrect.

Be sure to have the 3 options in Prefs-Security checked/on.

Open that page https://www.ebank.hsbc.com.au/
Enter a name/pw (anything)
Click on the red LogOn button just below the field.
A sheet appears "send unencrypted" data.
The Status bar shows a Blue Lock on the right.

Comment 4

[Simon Fraser [no longer active]]

I think this happens because the submit action of the form is a
"javascript:formSubmit();" URL.

Comment 5

[John Keiser (jkeiser)]

This is a bug in Mozilla too.  I haven't seen it before.  Probably form
submission but could be PSM's dialogs.

Comment 6

[Kai Engert (:KaiE:)]

You are using a build based on Mozilla 1.0.1, which does not contain the fix
from bug 151250.

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

Comment 7

[John Keiser (jkeiser)]

kaie, I am seeing this in WinXP 2003012908.  But that bug does not seem to have
regressed.

Rob, the page that you submit to is actually https, correct?

Comment 8

[Kai Engert (:KaiE:)]

I can't test with that page, something is wrong. When I connect with recent
versions of Netscape/Mozilla, I get an error message about an unsupported
browser. But even if I connect with Communicator 4.x, which they say they
support, I get the same error page...

Comment 9

[Alex]

This bug occurs on the same site as the evangelism bug I submitted
<http://bugzilla.mozilla.org/show_bug.cgi?id=205631>.

When accessing <https://www.ebank.hsbc.com.au/> with mozilla-on-gnu-linux, a
page comes up asking you to use a supported browser (by the way, the list of
"supported" browsers is incorrect - Communicator 4.79 doesn't work on linux or
windows2000 for this site).  When accessing with mozilla-on-windows2000, the
normal login page appears, but when the "login" button is pressed a warning
comes up about unencrypted information being sent over the https connection.  I
have no access to mozilla on other OS, so I don't know which of the two problems
occurs with them!

I think most of this is hsbc.com.au's fault, but when I emailed them they
replied "linux is not a supported OS".  That is why I submitted this as an
evangelism bug with mozilla-on-gnu-linux, but the "submitting unencrypted"
message on W2K is a little disturbing.

Hope this helps.

Comment 10

[Daniel Veditz [:dveditz]]

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

Comment 11

[Daniel Veditz [:dveditz]]

Not sure what site bug 277293 represents. Also broken is
https://www.midamericabank.com/log_into.cfm doing the same
action="javascript:validate()" submitting a hidden form kind of thing.

Comment 12

[Tal]

(In reply to comment #11)
Daniel,
bug 277293 is a general one. As suggested on comment #4, this happens for me 
in every page I got with "javascript:formSubmit();" (you can use any name you 
want on instead of the formSubmit()). I can send you the source for a simple 
test if you wish.

Comment 13

[Asa Dotzler [:asa]]

Dan, or Kai, are you going to be able to look into this for beta2 and Firefox
1.1? Moving blocker status to beta2 with fingers crossed.

Comment 14

[Kai Engert (:KaiE:)]

I'm sorry, I don't have time.

Comment 15

[Daniel Veditz [:dveditz]]

Ok, I'll take a crack

Comment 16

[Iain MacDonnell]

I've just run into this, trying to create a page that constructs a URL based on
the values input in a form and then "goes to" that URL. The form's action is
"javascript:goThere()", which is my function defined in the header of the page.
When accessed through https, firefox warns on submit that the data is being sent
through an unencrypted connection. It works fine in IE and Safari.
 

Comment 17

[Iain MacDonnell]

Attachment: Patch to allow posting to JavaScript form action URLS without security warning

Here's a simple patch that checks the action URL to see if it's JavaScript, and

allows it to pass if so. I'm not sure if this is the best answer - eg. are
there
other non-connection-based form actions that should pass through also?

Who needs to review this?

Comment 18

[Daniel Veditz [:dveditz]]

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

Comment 19

[Asa Dotzler [:asa]]

moving out to 1.8b3

Comment 20

[Aaron Slunt]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050609
Firefox/1.0+

Comment 21

[Asa Dotzler [:asa]]

moving to beta4

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 176692 [details] [diff] [review]
Patch to allow posting to JavaScript form action URLS without security warning

r=dveditz

Comment 23

[Darin Fisher]

Comment on attachment 176692 [details] [diff] [review]
Patch to allow posting to JavaScript form action URLS without security warning

>Index: nsSecureBrowserUIImpl.cpp

>+nsresult
>+nsSecureBrowserUIImpl::IsURLJavaScript(nsIURI* aURL, PRBool* value)
>+{
>+	*value = PR_FALSE;
>+
>+	if (!aURL)
>+		return NS_OK;
>+
>+  return aURL->SchemeIs("javascript", value);
>+}

This code appears to be mixing tabs and spaces.  It is generally
preferrable to replace all tabs with spaces for readability.


>+  // Action is a JavaScript call, not an actual post. That's okay too.
>+  if (actionJavaScript) {
>+    return NS_OK;
>+  }

What about data: URLs?


sr=darin

Comment 24

[Daniel Veditz [:dveditz]]

> What about data: URLs?

They don't make a lot of sense as an action -- they're not going to get the post
data, and they replace the current document and won't have access to the form
itself. No one's mentioned any problems with data:, but javascript: is fairly
common.

javascript: could be used to pass unencrypted data back, but if the page is
malicious it could do that anyway apart from the submit action. Legit cases use
the javascript to clean the data and populate a hidden form and then submit that
-- and that hidden form is going to get checked.

Comment 25

[Hixie (not reading bugmail)]

See also:
   http://whatwg.org/specs/web-forms/current-work/#for-javascript
   http://whatwg.org/specs/web-forms/current-work/#for-data

Comment 26

[Daniel Veditz [:dveditz]]

(In reply to comment #25)
> See also:
>    http://whatwg.org/specs/web-forms/current-work/#for-javascript
>    http://whatwg.org/specs/web-forms/current-work/#for-data

That's an interesting use for data:, and you could file an RFE on it. But a page
under development is probably not on an SSL server, and even if it is it's not
going to kill the developer to put up with some unencrypted form warnings.

Comment 27

[Hixie (not reading bugmail)]

Oh I wasn't saying that it should affect this, just letting you know about it. :-)

Comment 28

[Daniel Veditz [:dveditz]]

Checking in nsSecureBrowserUIImpl.cpp;
/cvsroot/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.cpp,v  <-- 
nsSecureBrowserUIImpl.cpp
new revision: 1.47; previous revision: 1.46
done
Checking in nsSecureBrowserUIImpl.h;
/cvsroot/mozilla/security/manager/boot/src/nsSecureBrowserUIImpl.h,v  <-- 
nsSecureBrowserUIImpl.h
new revision: 1.17; previous revision: 1.16
done

Comment 29

[Daniel Veditz [:dveditz]]

Although fixed before the branch, the blocking1.8b5+ flag is causing this to
show on queries without the fixed1.8 keyword. Should it regress I don't want to
lose the blocking flag and can no longer set the b4+ flag.