[WEB SECURITY] Defending users of unprotected login pages with TrustBar 0.4.9.93

[Amir Herzberg]

On 9/23/05, Gervase Markham <gerv at gerv.net> wrote:
>
> ...
> > How could you prevent compromise of the signature if the page was
> > compromised?
> >
> > This is actually easy. The server digitally signs the page and puts the
> > signature in the page;
>
> Wouldn't that break the signature?


No, the signature is not done over itself (this tag is excluded) - this is a
standard solution, see e.g. in XML-DSIG, don't worry about this.

> TrustBar (or browser) can easily validate the
> > signature, using the public key of the server (of course extracted
> > securely from a certificate signed by a trusted CA). So this is as
> > secure as SSL. But does require site cooperation, of course.
>
> And if the site is going to cooperate, it would be much easier for them
> to provide an SSL login!
>
> Let's not invent inadequate solutions where good ones exist :-)


Well, I almost agree; however, I must say, that there are some legitimate
issues that sites have with using SSL over their homepage, and they still
want (for business considerations) to have login in their homepage - this is
why they don't use SSL in the first place. So while I'll love them to use
SSL, I'm trying to find a solution that will allow them to work w/o SSL in
the homepage. Still, as I said, the fact sites must cooperate is the real
problem with signing these non-SSL login pages.

> Suppose that whenever a user assigns name/logo to an unprotected page,
> > we also save a copy of that page, and compare such copies for five
> > accesses (or over a period of at least five days). If we find the page
> > is static (except possibly for few bytes here and there),
>
> How many? I can control a page if I can inject:
>
> <script src="http://x.yz/q"/>


Yes, I know, this is tricky, we definitely will need to try to prevent such
changes... This seems hard.

> The difference is in what we do if the page does change (in new
> > locations). What I think of doing is simply to *display the archived
> > version* - with a message / button allowing user to use the new version
> > instead if needed. I think in most cases, even if there are changing
> > fields in the page, using the old version will still work.
>
> My first thought is that it'll break websites in a non-discoverable way.
> If, for example, the name of the login parameter form field changes, the
> old page will still be submitting the wrong value.


Yes, this is a valid concern, and maybe killer.

One alternative would be that when such a change is detected, TrustBar will
try to load the page from another channel, e.. via some secure proxy. That
will protect against most attacks, which exploit some local vulnerability
(typically of DNS).
--
Amir Herzberg
Associate Professor, dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20050925/cb37c758/attachment.html>