Closed Bug 138684 Opened 22 years ago Closed 22 years ago

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

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aoliva, Assigned: john)

References

()

Details

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:

Atenção:  
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:
Atenção:  
  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.
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()">

                         ETC.
                         ETC.

<td>&nbsp;</td><td height="19" valign="bottom"  class="loginTitulo">
<applet tabindex="4" code='br/com/bb/aapf/bbteclado/CampoTeclado.class'
        cabbase='/aapf/imagens/teclado/BBTeclado001.cab'
        archive='/aapf/imagens/teclado/BBTeclado001.jar'         
        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>
<a 
href="http://www.bancobrasil.com.br/appbb/portal/bb/ds/ajudaTecladoVirtual.jsp">
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">
</applet>

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



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 

             document.form.elements['senhaConta']


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:


FROM JS DEBUGGER:
---------------------------------------------------------------------------

document.applets['tclJava']
[HTMLAppletElement] [class: HTMLAppletElement] {0}

senha
[JavaObject] [class: JavaObject] {0}

senha.toString()
[JavaObject] [class: JavaObject] {0}

senha
[JavaObject] [class: JavaObject] {0}

senha.length()
[integer] 4

senha.charAt(0)
[integer] 49
senha.charAt(1)
[integer] 50
senha.charAt(2)
[integer] 51
senha.charAt(3)
[integer] 52

senha + '';
[string] "1234"

String(senha);
[string] "1234"
---------------------------------------------------------------------------
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
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 

             document.form.elements['senhaConta']


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


FROM JS DEBUGGER:
---------------------------------------------------------------------------
document.form.elements['senhaConta'].value
[void] void

document.form.elements['senhaConta']
[HTMLCollection] [class: HTMLCollection] {0}
---------------------------------------------------------------------------
Assignee: rogerl → jst
Component: Live Connect → DOM Level 0
QA Contact: pschwartau → desale
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:

---------------------------------------------------------------------------
senha
[JavaObject] [class: JavaObject]

typeof senha
[string] "object"

senha.__proto__
[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(senha);
[string] "1234"
---------------------------------------------------------------------------



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

---------------------------------------------------------------------------
document.form.elements['senhaConta'].outerHTML;
[void] void

document.form.elements['senhaConta'].innerHTML;
[void] void

document.form.elements['senhaConta'].parent;
[void] void

document.form.elements['senhaConta'].__parent__;
[Window] [class: Window]
---------------------------------------------------------------------------
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
*** Bug 144206 has been marked as a duplicate of this bug. ***
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?
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");
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. ***
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.
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.
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>
----------------------------------------------------
java.lang.NullPointerException

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

	at
sun.net.www.protocol.http.HttpURLConnection.setPreemptiveProxyAuthentication(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.AbstractDelegateHttpsURLConnection.setProxiedClient(DashoA6275)

	at
sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.superConnect(Unknown
Source)

	at
sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.access$100(Unknown
Source)

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

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

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

	at
sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.getInputStream(Unknown
Source)

	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)

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.
Paulo,

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 :)
Oops!
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.
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.
Status: NEW → RESOLVED
Closed: 22 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.

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

Java(TM) Plug-in1.4.1_02
WORKSFORME with stock Mozilla in Red Hat Linux 9 (mozilla-1.2.1-26), with
j2re-1.4.1_01-fcs
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.