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

[Gervase Markham <gerv@xxxxxxxx>]

Amir Herzberg wrote:
> Well, shame them - how? I would think the Hall of Shame is about the 
> best I know how to do. I would appreciate help in making this shameful 
> situation more visible to the public... For example, maybe you (and 
> other security-concious folks) can link to the Hall of Shame from 
> relevant webpages and articles.

Indeed. If you make a quality "Hall of Shame", perhaps covering other 
issues as well as unprotected logins, and giving each bank a "security 
rating", that's the sort of thing that publicity could be generated around.

>     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?

> 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 :-)

> 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"/>

> 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.

Gerv

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/