bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Account password entered in Java applet does not get through to the server




DOM: Core & HTML
16 years ago
15 years ago


(Reporter: Alexandre Oliva, Assigned: John Keiser (jkeiser))



Firefox Tracking Flags

(Not tracked)





16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

Below `Agencia' and `Conta', on the left of the web page, there's a Java applet
in which you're supposed to enter your password.  No matter what I enter there,
after I click on the `entra' button, I get back the same web page, now with an
error message in red below the applet, saying `Atenção: senha: conteúdo nulo'
(meaning Attention: password: null contents).

The same web page works fine on Netscape 4.79-1, on the same machine and OS.  It
fails similarly with Mozilla 0.9.9 included in Red Hat Linux skipjack-beta2,
using Sun JRE 1.4.0 as the Java plug-in, and with Mozilla 0.9.9 on MS-Windows 2000.

Reproducible: Always
Steps to Reproduce:
1.browse to that web page
2.enter `1-9' for both `Agência' and `Conta' (otherwise the check-digit
verification will fail before the password is tested)
3.enter anything at all as the `Senha de auto-atendimento' in the Java applet
4.click on `entra'

Actual Results:  An error message saying the password as blank is displayed:

Senha: Conteúdo nulo !

Expected Results:  If an incorrect password, with 8 digits or longer, is
entered, you should get to a web page saying `DADOS NAO CONFEREM'.  If a
non-blank password that is too short is entered, you'll remain in the same web
page, with a message saying the password must have at least 8 characters:
  Senha: Conteúdo deve ter no
     mínimo 8 caracteres !
If the correct password were entered, you'd gain access to the account, but
you're not supposed to get that far :-)

I'm notifying the bank that some people may be trying out odd passwords on that
web page for account 1-9 1-9.  Hopefully this won't be a problem :-)

I'm not really sure this is a problem with LiveConnect, but I found some similar
bug reports in this category, but they appear to affect Mac platoforms only, so
I thought I'd report it anyway.

Comment 1

16 years ago
Confirming reported behavior with Mozilla trunk binary 20020415xx WinNT.
OS: Linux ---> All.

But I can't see any problem with the pure LiveConnect at the site. 
Here's how it's coded:

<form action="/aapf/aai/login.pbk" method="POST" name="form"
      autocomplete="off" onSubmit="getSenha()">


<td>&nbsp;</td><td height="19" valign="bottom"  class="loginTitulo">
<applet tabindex="4" code='br/com/bb/aapf/bbteclado/CampoTeclado.class'
        codebase='/aapf/imagens/teclado/' name='tclJava' id='tclJava'
        width='167' height='89' mayscript>

<param name='local' value='login'>
<param name='campoAnterior' value='numeroContratoOrigem'>
<param name='campoPosterior' value='botaoOk'>
<param name='colorLabel' value='0x000084'>
<param name='colorField' value='0xFFFFFA'>
<param name='colorBorder' value='0xBBBBBB'>
<param name='colorBackground' value='0xF7F7F7'>

Para sua segurança,<br>
clique aqui</a> e habilite o seu teclado virtual até 24/04/2002<br>
<font class='nomeInput11'>Senha de Auto-Atendimento</font><br>	

<input type="password" name="senhaConta" maxlength="8" size="10" tabindex="4">

<input type="hidden" name="senhaConta" value="">
<input type="hidden" name="botaoOk.x" value="">

The onSubmit handler for the form, getSenha(), is coded as follows, from
view-source:https://www2.bancobrasil.com.br/aapf/includes/formatadadosns2.js :

function getSenha()
  if ( document.applets['tclJava'] )
    var senha = document.applets['tclJava'].getSenha();
    document.form.elements['senhaConta'].value = senha;

Note the function tries to assign the value |senha| to the element 


This session from the Mozilla JavaScript Debugger shows that the
pure LiveConnect is working properly. I entered '1234' in the 
'Senha de auto-atendimento' input in the Java applet, hit the
'entra' button, and got the correct value |senha| coming out:


[HTMLAppletElement] [class: HTMLAppletElement] {0}

[JavaObject] [class: JavaObject] {0}

[JavaObject] [class: JavaObject] {0}

[JavaObject] [class: JavaObject] {0}

[integer] 4

[integer] 49
[integer] 50
[integer] 51
[integer] 52

senha + '';
[string] "1234"

[string] "1234"
Ever confirmed: true
OS: Linux → All

Comment 2

16 years ago
Reassigning to DOM Level 0 for further analysis, but this
could be an OJI issue; I can't tell -

Idea: perhaps we're getting a conflict between the two <input> elements
defined above. One is inside the applet, the other one is outside it,
but they both have the same name, 'senhaConta':

<input type="password" name="senhaConta" maxlength="8" size="10" tabindex="4">
<input type="hidden"   name="senhaConta" value="">

So when the onSubmit handler for the form above, getSenha(),
tries to assign the value |senha| to 


which of the two is |senha| getting sent to? That may be the problem here -

[void] void

[HTMLCollection] [class: HTMLCollection] {0}
Assignee: rogerl → jst
Component: Live Connect → DOM Level 0
QA Contact: pschwartau → desale

Comment 3

16 years ago
Another idea: perhaps Mozilla IS finding the correct <input>
'senhaConta' when trying to make the assignment

      document.form.elements['senhaConta'].value = senha

But perhaps the DOM is failing to make the assignment from 
the JavaObject |senha|. It is of Java class java.lang.String,
I believe, from this session in the Mozilla JS debugger:

[JavaObject] [class: JavaObject]

typeof senha
[string] "object"

[Object] [class: Object]

var s = ''; for (p in senha) {s+= p + ' = ' + senha[p]};  print(s);
Caught exception: InternalError: Java class java.lang.String has no
public field or method named "nodeName"

I'm wondering if the DOM is failing to extract the character data out
of the JavaObject |senha|. The data is there, as we saw in Comment #1,
but perhaps the DOM isn't extracting it successfully. Note that in my
debugging from Comment #1, I did this to get the character data:

senha + '';
[string] "1234"

[string] "1234"

Meanwhile, trying to track down document.form.elements['senhaConta'],
this is all I could think of to try :

[void] void

[void] void

[void] void

[Window] [class: Window]

Comment 4

16 years ago
Following jst's suggestion, I loaded the site in IE6 and Mozilla
and used javascript:alert() to make these comparisons:
                                                            IE6     MOZ

document.getElementsByTagName('input').length                6       7
document.applets[0].getElementsByTagName('input').length     0    no alert!
document.getElementsByName('senhaConta').length              1       2
Over to jkeiser per discussion on #mozilla...
Assignee: jst → jkeiser

Comment 6

16 years ago
*** Bug 144206 has been marked as a duplicate of this bug. ***

Comment 7

16 years ago
FWIW, I've just been surprised to find out that this works fine on AOL Netscape
6.2.2, on Red Hat Linux 7.3 (using Sun JRE 1.4; the JRE that ships with AOL
Nescape crashes as the web page opens, even with LD_ASSUME_KERNEL=2.2.5).

Any chance of having the fix merged into Mozilla 1.0?

Comment 8

16 years ago
Ok, so it was not a bug fix in Netscape 6 that fixed the problem, after all.
Simply adding `Netscape6' to User-Agent was enough to get this web page going
just fine with Mozilla 1.0rc2.
/me grumbles about web site developers that don't care about Mozilla...
Any chance of getting `Netscape6' added to the default user-agent compatibility
list?  Or perhaps of having some means to *add* information to the User-Agent,
instead of completely overriding it?
Anyway, here's what I have in prefs.js for now:
user_pref("general.useragent.override", "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.0rc2) Gecko/20020510 Netscape6");

Comment 9

16 years ago
Adding Brazilian evang expert who has been involved in this discussion with the
site at hand.
*** Bug 159772 has been marked as a duplicate of this bug. ***
*** Bug 144616 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
Of course, just a few days after I found the work around, the web developers at
the bank seem to have found a way to prevent me from using their web banking:
the Java applet now freezes all of Mozilla when I use it.  Eek.

But I found a nice work-around: using the Mozilla user Agent Override side bar,
http://mozilla-evangelism.bclary.com/sidebars, I add `Macintosh' to the user
agent string and, voila, the web page that is presented doesn't require Java at
all any longer.

Comment 13

16 years ago
Phil, you were correct on comment #2. I'm in contact with them and they removed
the input type inside the applet tag, so the password is now going to the server.

A weird behavior now is that when you move focus to the applet, the text cursor
continues on the HTML text field. I created bug 162317 for this.

Comment 14

16 years ago
Below is is a copy of the Java errors (first line,
"java.lang.NullPointerException" is visible in the gray area where the applet
should have painted its window).
Picked this with 1.0rc1 but it's the same with the latest builds.


Java(TM) Plug-in: Version 1.4.0_01
Using JRE version 1.4.0_01-ea Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\PJ

Proxy Configuration: Browser Proxy Configuration

c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
l:   dump classloader list
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system properties
t:   dump thread list
x:   clear classloader cache
0-5: set trace level to <n>

	at sun.net.www.protocol.http.AuthenticationInfo.getProxyAuth(Unknown Source)


	at sun.net.www.protocol.http.HttpURLConnection.sendCONNECTRequest(Unknown Source)

	at sun.net.www.protocol.http.HttpURLConnection.doTunneling(Unknown Source)




	at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection$2.run(Unknown

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.connect(Unknown


	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(DashoA6275)

	at sun.plugin.net.protocol.http.HttpUtils.followRedirects(Unknown Source)

	at sun.plugin.cache.CachedJarLoader.download(Unknown Source)

	at sun.plugin.cache.CachedJarLoader.load(Unknown Source)

	at sun.plugin.cache.JarCache.get(Unknown Source)

	at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)

	at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)

	at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source)

	at sun.misc.URLClassPath$JarLoader.<init>(Unknown Source)

	at sun.misc.URLClassPath$2.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.misc.URLClassPath.getLoader(Unknown Source)

	at sun.misc.URLClassPath.getLoader(Unknown Source)

	at sun.misc.URLClassPath.getResource(Unknown Source)

	at java.net.URLClassLoader$1.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at java.net.URLClassLoader.findClass(Unknown Source)

	at sun.applet.AppletClassLoader.findClass(Unknown Source)

	at sun.plugin.security.PluginClassLoader.findClass(Unknown Source)

	at java.lang.ClassLoader.loadClass(Unknown Source)

	at sun.applet.AppletClassLoader.loadClass(Unknown Source)

	at java.lang.ClassLoader.loadClass(Unknown Source)

	at sun.applet.AppletClassLoader.loadCode(Unknown Source)

	at sun.applet.AppletPanel.createApplet(Unknown Source)

	at sun.plugin.AppletViewer.createApplet(Unknown Source)

	at sun.applet.AppletPanel.runLoader(Unknown Source)

	at sun.applet.AppletPanel.run(Unknown Source)

	at java.lang.Thread.run(Unknown Source)

Comment 15

16 years ago
I verified today that the applet now loads so the virtual keyboard and the
password field are shown correctly.
However, one is required to enter password by clicking on the virtual keyboard,
because the cursor does not show up on the password field and keyboard
keystrokes do not pass thru.

Comment: the virtual keyboard was introduced as a security measure, to difficult
scooping the keyboard buffer or else; however, it makes it exceedingly easy even
for a non-criminal looking over the shoulder to follow the cursor movement and
discover the password - it is much easier to cover the keyboard are with the
body if one is in a public place.

Comment 16

16 years ago

Additional comment #2 shows that there are 2 fields with the exact same name for
the password, which appears to be confusing Mozilla when you hit TAB. 
About the security of clicking on buttons for the password, I already asked this
to myself a lot :)

Comment 17

16 years ago
My last comment was not precise, sorry for that.

I was mislead because the cursor doesn't appear on the screen; however, if one
clicks over the password field and enters numbers, asterisks appear after each
number entered so it is possible indeed to enter a complete password.

Not entirely fixed because of the invisible cursor but functional.

Comment 18

16 years ago
Marking fixed from comments above.  I don't see the invisible cursor problem
either, but if that still exists, please file a new bug that references this one.
Last Resolved: 16 years ago
Resolution: --- → FIXED
Unfortunately this bug is back.

The site has changed and now I can't login.

The work around (using Macintosh in the user agent) does not work either.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Java(TM) Plug-in1.4.1_02

Comment 20

15 years ago
WORKSFORME with stock Mozilla in Red Hat Linux 9 (mozilla-1.2.1-26), with
Right... it works with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Java(TM) Plug-in1.4.1_02

But you cannot use TAB to change focus from field "conta" to "senha de
auto-atendimento". Actually, it changes focus from "conta" to "entrar" button.

If you use TAB it won't work.

You must leave focus in "conta" and enter the password. Then click "entrar".

This way it works.
You need to log in before you can comment on or make changes to this bug.