Re: Growing Bad Practice with Login Forms

[Devin Heitmueller <dheitmueller () netilla com>]

On Tue, 2004-07-27 at 10:12, Konstantin Ryabitsev wrote:
> In fact, presenting the login form on the SSL page won't win you
> anything, since there is no guarantee that you will submit your data to
> the same SSL-enabled server than the one that sent you the login form.

Ah, but wait.  If the Login page itself is on an SSL enabled server, you
can be assured that the POST will be sent to the same server since the
POST destination is in the HTML from the login page (assuming you trust
the SSL site to begin with).  If the login page is not on an SSL enabled
webserver, the login page can be spoofed and the contain a form pointing
to some non-SSL site.

Here's the attack vector:

1.  User attempts to connect to HTTP login page
2.  Attacker spoofs login page with HTML containing POST destination of
his own website (doesn't even need to be SSL).  
3.  User receives HTML form containing POST destination to false login
CGI
3.  User submits form to attacker's non-SSL website.  By the time you
realize you weren't prompted to enter an SSL enabled website, your
credentials have already been sent.

This attack is prevented by having the login page be SSL secured.  This
way, you know that you are on a secure site when presented with the
login page, and can be assured that your credentials will be sent to the
correct destination.

-- 
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc.

Attachment: signature.asc
Description: This is a digitally signed message part