Re: Growing Bad Practice with Login Forms

[Paul Johnston <paul () westpoint ltd uk>]

Mark,

I think you're right - this is bad practice. My first thought was that 
if browsers showed you the form target when you hovered over the submit 
button, that would be a good mitigation. Of course JS can fiddle with 
status bar and form targets. Better mitigation still if all JS 
controlled status bars came up in a different font/colour, and there was 
a warning about js changing the target of a form/link. However, there's 
still the potential for JS to access an image on the onsubmit or onblur 
events that leaks the username/password. So ultimately I think there's 
no mitigation, other than for the originating page to use SSL.

BTW, a couple of people mentioned source code designed to confuse people 
reading it and the possibility of tools to help with this. One such tool 
is the Mozilla DOM inspector, try it out sometime.

Best wishes,

Paul



Mark Curphey wrote:

> I am seeing more and more sites implementing a bad practice with login
> forms.
>
> To pick on a high profile site that should know better take ISACA as an
> example.
>
> http://www.isaca.org/
>
> In the top left hand corner you will see their secure login button and a
> graphical padlock embedded into the HTML. Of course if you look at the form
> tags, this does indeed submit the form over SSL and in the process the SSL
> handshake checks the certificate and my browser should verify that I am
> indeed sending my password to isaca.org. 
>
> But at that point its too late. The check for server authentication is done
> after I have sent by username and password. This IMHO is a bad practice that
> has started to creep into other sites including online banking. 
>
> I have added the issue to the OWASP Pen Test CheckList.
>
>
>  

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul () westpoint ltd uk
web: www.westpoint.ltd.uk