full-disclosure - Insecure http pages referencing https form-actions.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Wed Aug 10 00:34:46 2005
From: fd at ew.nsci.us (fd@...nsci.us)
Subject: Insecure http pages referencing https
	form-actions.

Today I realized that many "secured" web sites reference their secure 
login page from an insecure page.  For example:

http://www.some-luser.com/login.html:
  <form action="https://cgi.some-luser.com/login-cgi">
    user: <input name=user> 
    pass: <input name=pass>
  </form>

The actual post is secure (several assumptions made), but not the page
which contains the form itself!  In my mind, it would be rather trivial to
man-in-the-middle or DNS poison www.some-luser.com and change the content
of login.html's form-action to http://not-secure-luser.com/login-cgi.  If
Eve hosts not-secure-luser.com then login credentials will be posted to
her rather than to where it is expected.

With some javascript magic, Eve could even post the victim back into
https://cgi.some-luser.com/login-cgi.  Except for the extra delay and
perhaps a "please wait while you are logged in" page (ajax anyone?), Bob
*and* Alice would never know.

Am I missing something here?  Are "secure" web designers really
overlooking the obvious?

-Eric

--
Eric Wheeler
Vice President
National Security Concepts, Inc.
PO Box 3567
Tualatin, OR 97062

http://www.nsci.us/
Voice: (503) 293-7656
Fax:   (503) 885-0770

--
Here's a topic: foo.  Discuss amongst yourselves ...