152175 - firstdirect.com - apparently insecure online banking with Mozilla 1.0

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English Other, defect)

Description

[monkaaay]

Mozilla build 2002053012 on Win2k

Navigating the "internet banking" facility on the HSBC First Direct site leads
to an insecure site broken padlock. Clicking says the site is secure.

Reproducible: Always

Steps to Reproduce:
You must be a First Direct customer with internet banking set up to reproduce
the problem.

1. Navigate to URL www.firstdirect.com
2. Select "Internet Banking" from the drop down menu.
A new window will appear without a Location bar. Right-clicking is disabled. The
page uses frames.
This window *is* at a secure site. The padlock is shown as UNbroken.
4. Log in as usual.
5. The padlock will remain unbroken until an item from the menu on the left is
chosen, for example "send message". Once an item has been selected, the padlock
will break. Double-clicking the padlock leads to a report that the site *IS*
secure, despite the red background of the broken padlock.

Actual Results: May or may not remain secure. See description.
Expected Results: Remain secure.

Comment 1

[monkaaay]

First Direct report that Mozilla is not standard compliant.
I challenged them on this. They apologised.
"Mozilla does not support 128 bit encryption".

Oh dear.

Comment 2

[Kai Lahmann (is there, where MNG is)]

uhm.. we do, Mozilla even supports 168Bit, if they want!

Comment 3

[Jackson]

I can confirm that I get the same problem with both Mozilla 1.1b and 1.2a on
Linux. I'd say this was quite important - is Mozilla secure with this bank or not?

Do any developers have First Direct accounts though (or testing accounts?)

Comment 4

[Jackson]

If you log into the site, then disable javascript, it enables you to right-click.

If you then open each frame in a new window, each frame warns that the page
being opened is an encrypted page.

I can see two places in the javascript code where insecure sites could sneak in.
One is a test to see if parent.app is defined. If it doesn't, alternateUrl is
loaded, which contains a url beginning http://

Here's the function:
function formatAppURL(stdUrl,alternateUrl)
{
        if (parent.app)
        {
                var lDta;
                lDta=stdUrl;
                var params=new String(parent.location).split("?");
                if (params.length > 1)
                {
                        var elements=params[1].split("/");
                        if (elements.length >= 3)
                        {
                                lDta+='&CustLoginId='+elements[1];
                                lDta+='&SupportRef='+elements[2];
                                lDta+='&SaveinCookie=UNSELECTED';
                                lDta+='&MODIFIER=NEWUSERUPDATE';
                        }
                }
                parent.app.document.location.href=lDta;
        }
        else
        {
                top.document.location.href=alternateUrl;
        }
}

Is this the culprit?

Comment 5

[siddarz]

I have an account with First Direct - I've recreated this on Linux and 
Win98 with build 20020826, which gets a "secure/non-secure" warning 
then a red line thru the padlock. According to Ethereal however, the HTTP 
traffic stays as SSLv3 throughout the session with no unsecure packets 
sent or received.

According to "an anonymous source" (a friend who works with the people 
that built the service), the "alternateURL" script is for people using 
the wrong (guessed at) address, or trying to frame or spoof the site - 
it is meant to send the visitor back to the bank's homepage. If that 
script is called, the browser window loses it's connection to the secure 
server so alternateURL being an unsecure page isn't an issue - if the 
browser is told to request it, you're leaving the service, not staying 
logged on. If the browser requests it beforehand, it's not doing what it 
should.

Also, according to Anon, the secure server for the banking site only 
makes secure connections - it doesn't transmit using anything but SSLv3 - 
so there are no unsecure items sent once you've logged on and no 
requests for unsecure items are answered by the server. The fact that 
everything shows up when the brwoser requests it shows that no unsecure items 
are being received or requested by the browser.

In any case, the bank doesn't write code for, or test, Mozilla. What's 
there now is a hangover from when Netscape 4.6  was supported and 
they've told me previously that there are no plans to write for Mozilla. 
From what I've seen so far tho, this issue doesn't lie with the bank's 
code.

Comment 6

[Jackson]

They have no plans to write for Mozilla?

How about plans to write standards compliant HTML?

Comment 7

[GavinS]

Note that when you click on one of the left-hand menu items, you (now?) get a
dialog from mozilla saying that 'some of the items on this page are
un-encrypted' (or something similar to that).

The red line on the padlock remains, however.

On a related note, I get a bus error when I click on 'close' to close the popup
window on Solaris/sparc on recent nightlies -- do any other first direct users
see this?

Comment 8

[Pascal Chevrel:pascalc (PTO until April 26)]

New Component

Comment 9

[Bob Clary [:bc] (inactive)]

en other default owner

Comment 10

[chris hofmann]

one of the best references/recommendations I've found for encouraging financial institutions to support firefox is located at bankers on-line web site 

http://www.bankersonline.com/security/security_browserthreat070204.html 

It was written in 2004 during the download.ject attack, but much of it still applies today.  This is a good link to send when contacting banks.

Comment 11

[Chris Lawson (gone)]

Do any of you who were seeing this *still* see this? I see no problems going as far as I can without an account.

Comment 12

[Raj Bhaskar]

First Direct no longer complains about Mozilla security and the site works fine with Firefox 3.0.9 and with SeaMonkey 1.1.17 (appending Firefox/2.0 to the UA, otherwise although you can login without the UA change, the main online banking page doesn't load properly - bad browser sniffing?)

Comment 13

[Chris Lawson (gone)]

Raj, can you please file a *new* TE bug on comment 12? If I understand you correctly, they're serving up broken content to browsers that do not include "Firefox" in the UA string. Is that accurate?

The original issue here sounds like it's FIXED based on comment 12.

Comment 14

[Raj Bhaskar]

(In reply to comment #13)
> Raj, can you please file a *new* TE bug on comment 12? If I understand you
> correctly, they're serving up broken content to browsers that do not include
> "Firefox" in the UA string. Is that accurate?
> 
> The original issue here sounds like it's FIXED based on comment 12.

I see the issue in comment 12 in SM 1.1.17, but it seems to be working fine in a recently self-compiled build of SeaMonkey 2.  Should I still go ahead and file a new bug?

Comment 15

[Chris Lawson (gone)]

Yeah, if you can reproduce with any Gecko browser lacking "Firefox" in the UA string, please do.

cl

Comment 16

[Raj Bhaskar]

Filed bug 503974.