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>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.50.0508091735450.10134-100000@kegger.national-security.net>
Date: Wed Aug 10 02:26:46 2005
From: fd at ew.nsci.us (fd@...nsci.us)
Subject: Insecure http pages referencing https
	form-actions.

On Tue, 9 Aug 2005 douglas.foster@...il.com wrote:

> On 8/9/05, fd@...nsci.us <fd@...nsci.us> wrote:
> > 
> > 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>
> > 
> Could you be mixing up the secure communication of https, with the
> host security of the server hosting the login page?  Anyone who breaks
> into a https host can alter the page code, just the same as if they
> broke into a http server.  And it only takes a registered domain to
> receive a https certificate, so not-secure-luser.com would still have
> a lock at the bottom of the page.

Access to the host which holds the http copy of login.html is not
necessary, but would serve similarly.  The change of the login page
happens with DNS poisoning to point somewhere else, or, by simply changing
the content of the http (not https) stream..  

Since the page holding login.html is insecure (http), redirecting and/or
changing content is trivial.  Note that the new action is changed to
http://not-secure-luser.com/login-cgi, not https so we don't even need a
real certificate.

You are correct, there will be no padlock - but it is too late.  By the
time they realize that the login doesn't give them a secure page, their
credentials have been snarfed.  In addition, Eve's page
http://not-secure-luser.com/login-cgi could spit out something like this:

<h1>
  <!-- Your password is now mine.  -->
    Please wait while you are logged in
  <!-- where you expected to be ... -->
</h1>
<form name=foo action="https://cgi.some-luser.com/login-cgi">
    <input name=user type=hidden value=$username>
    <input name=pass type=hidden value=$passwd>
</form>
<script>document.foo.submit();</script>

The victim would then be logged in to where they expected to be, complete
with padlock.  Except for the extra "please wait" page, this would not be
obvious to a user.  My issue is with the insecure location of the actual
<form> and I have seen many sites which do this (including major financial
institutions).

Does this help address your question?

-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