[WEB SECURITY] Web security improvement ideas
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
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
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
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.
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