Re: Growing Bad Practice with Login Forms

[Konstantin Ryabitsev <icon () phy duke edu>]

On Tue, 2004-07-27 at 10:28 -0400, Devin Heitmueller wrote:
> 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.

An SSL certificate is not a panacea against possible server problems. A
cracked server with an SSL certificate is just as cracked as the one
without one, except it puts the blame for anything gone wrong on the
server admins, not on any points in-between the HTTPD application and
the user browser.

Furthermore, let's modify the attack vector:

1. The user receives a spoof email with a trojaned link to an SSL-
enabled legitimate site, but which uses XSS to modify where the form is
submitted (I've done proof-of-concept attacks like that).
2. The user verifies the certificate and sees that it's a valid cert of,
say, a bank.
3. The user fills out a form and submits it, but the form gets submitted
to the attacker's site (it may as well have valid SSL -- the browser
won't warn you if you submit to a different site than the one that
presented you the form).

So, ultimately, SSL doesn't buy you anything -- it just guarantees[*]
you that the server that presented you the page is what it claims to be,
and that the transaction hasn't been sniffed or tampered with while it
was getting to your browser. Once the page is displayed to you, you're
outside that guarantee, and the fact that you accessed the page with the
form over SSL is largely irrelevant (session issues aside).

Regards,
-- 
Konstantin Ryabitsev
Duke University Physics

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