[WEB SECURITY] Web security improvement ideas

Ivan Ristic ivan.ristic at gmail.com
Fri May 27 04:09:43 EDT 2005

On 5/26/05, Gervase Markham <gerv at gerv.net> wrote:
> Ivan Ristic wrote:
> > A thick red line around the browser window? It doesn't matter as long
> > as it's clear the user is somewhere "safe".
> Do you think a thick red line around the browser window would make it clear?

I certainly think it would work much better than the small lock we
have now. But it's not a topic that interests me much. There seem to
be a lot of good quality papers on the subject out there already.

> >>I'm not sure going through a URI is necessary. My "Content Restrictions"
> >>proposal, which you may know of, implements this idea directly in the
> >>header: http://www.gerv.net/security/content-restrictions/
> >
> > The amount of information we wish to convey may be or become too large
> > for a header. That's why I prefer a simple link to a file. Plus I can
> > format the file any way I like and make it easy to read and
> > understand.
> But you need an extra HTTP request which must be completed probably even
> before parsing starts. This could add a half-second delay to page load,
> which is really significant. Plus (unless you use either an XML format
> or a very simple parser) you need an extra parser for your nice readable
> format.

I am sure the descriptor can be cached for the duration of the
session. XML format is fine by me.

> >>These three things together present a problem. Most SSL certs expire
> >>after a year. If the browser is to refuse to recognise expired certs,
> >>how can there by any upgrade process for the browser's cert cache?
> >
> > Because the browser would first encounter the current, valid,
> > certificate. It can then tell the server "prove to me you posses this
> > older certificate".
> By extensions to which protocol?

I think it would make a nice addition to TLS.

> > If the server cannot do that the trust would have
> > to be established again in some other way.
> What other way?

By the person trusting the web site, or ringing the bank up to send
them a pin, or by using the mutual authentication technique.

> >>Also, what
> >>happens if a person returns to a web app (say) 3 years later? Is the
> >>webserver to continue to server copies of all its previous certs for ever?
> >
> > Do you see a practical problem with that?
> Well, a hard disk crash on the server could mean that none of your
> customers ever trust you again.

They would be right, don't you think? There are well-established ways
to mitigate data-loss disasters. I don't think it's a problem that
falls within the scope of web application security. For example, if
you lose all your customers' passwords due to a disk crash you would
have to contact them all via snail mail to re-establish trust with
them. Assuming they still have their customers' addresses, that is.

> >>What problem are you trying to solve with these suggestions?
> >
> > If a user goes to a web site that looks like the real thing but it is
> > not I want the browser to be able to either detect that (if the
> > address is the same)
> If the address is the same but you are in the wrong place, SSL has
> failed completely. An SSL cert ensures that if your browser says
> "www.foo.com", then that's where the content came from.

That's exactly my point. I want another layer of security for cases
when SSL has failed completely. Are you arguing it cannot happen?

> > or tell me that I've arrived at a completely new
> > destination.
> If you are at a different destination, the browser should make it clear
> where you are. See Firefox's domain indicator for a step in the right
> direction.

But I don't want to think about it and neither does my mother.
Actually I am pretty sure my mother would not spot the difference.

> > Not quite, there is another issue. If the server can prove to you it
> > knows the password then you also know you are at the *correct*
> > location, which is not quite the same. E.g. imagine a web site
> > pretending to be your bank's web site. A login form appears, you enter
> > your password, and the web site behaves as if the authentication was
> > successful. So at this point you believe you are at the right place,
> > but the web site can try to trick you into disclosing your private
> > information in some other way.
> OK. So if you have SSL and Digest Auth with server auth, doesn't that
> solve the problem? Why do you need some sort of additional
> browser-integrated forms-based authentication?

It doesn't solve the problem. For the scheme to work
non-password-leaking authentication scheme must be mandatory.
Otherwise, phishers will just use what suits them (e.g. form-based
auth) and keep collecting the passwords.

> >>>* Design a mechanism for explicit log-out. And a mechanism for session timeout
> >>>  (in the browser). Delete all session information after it is terminated.
> >>
> >>Surely single-session cookies combined with an in-web-UI logout link
> >>achieve this?
> >
> > It can be achieved, but as a user I don't know whether it will be
> > done. Think about it simply as another layer of protection. If the
> > browser purges my credentials and the session information from memory
> > I should be safe no matter whether application is implemented
> > correctly or not.
> A great deal of security depends on correct implementation of the
> application. Why should the browser cover for the app in this particular
> instance?

A great deal of security depends on correct implementation of the
client. It's simply better to have both angles covered.

> BTW, there's no way you can make cookies or any session token
> invisible to the end-user; again, it's a privacy issue.

It doesn't really matter anyway. On a properly implemented system a
session token is worthless to the attacker.

Ivan Ristic
Apache Security (O'Reilly) - http://www.apachesecurity.net
Open source web application firewall - http://www.modsecurity.org

The Web Security Mailing List

The Web Security Mailing List Archives

More information about the websecurity mailing list