[WEB SECURITY] Web security improvement ideas

Ivan Ristic ivan.ristic at gmail.com
Thu May 26 07:02:19 EDT 2005

On 5/26/05, Gervase Markham <gerv at gerv.net> wrote:
> >   The idea is to market Secure Web Applications as really
> >   secure and everything else as potentially insecure. Visually, they should
> >   appear very different than the normal browsing experience.
> How would you create such a visual distinction while still giving the
> vast majority of the browser screen real estate to the application?

A thick red line around the browser window? It doesn't matter as long
as it's clear the user is somewhere "safe".

> > * Add one new HTTP header, to contain an URI to a descriptor that contains
> >   more information about a Secure Web Application. The descriptor should
> >   allow application authors to exercise great control over what happens in
> >   a Secure Web Application. E.g. they may decide not to use client-side
> >   code at all. Or not accept Flash objects (the browser should then refuse
> >   to run them even if they appear in HTML).
> 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

> It is backwardly-compatible with existing user agents.

So is a link to a descriptor.
> > * Browsers should remember the SSL certificate of a server upon the first
> >   visit of a web site. If the certificate changes browsers must refuse
> >   to communicate with the site.
> >
> > * Only valid certificates should be acceptable for Secure Web Applications.
> >
> > * Allow some mechanism for SSL certificates to be changed/upgraded. (Doesn't
> >   one already exist?) For example, the server could keep old certificates around
> >   to use them for the transition.
> 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". If the server cannot do that the trust would have
to be established again in some other way.

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

> 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) or tell me that I've arrived at a completely new
destination. And I don't want to be bothered with such uninteresting
events such as a legitimate SSL certificate change.

> > * Never use Basic authentication (because it sends passwords out in plain text).
> >   Allow only Digest authentication (does not send the passwords out at all) with
> >   mandatory server authentication (so the user knows he is at the right place).
> I agree that the user needs to know he's in the right place. Could you
> point to an explanation of this "server authentication" you mention?

The authentication methods in use today generally focus on the client
demonstrating (to the server) it knows the password. I am proposing a
transition to an authentication method that supports mutual
authentication, i.e. requires the server to demonstrate it knows the
password too (to the client). This idea is already part of Digest auth
but I don't think it was implemented anywhere.

> > * Form-based authentication must be integrated into browsers, and it too must
> >   be designed not disclose passwords (e.g use Digest auth). Clients must always
> >   authenticate servers. Some prior art available here:
> >   http://www.w3.org/TR/NOTE-authentform
> It seems to be that the only issue HTML forms and SSL together do not
> solve is the problem of sending your password to the wrong server. If
> the user can know they are in the right place or if you use HTTP Digest
> Auth, this problem also goes away.

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.

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

> > * Make SSL mandatory.
> >
> > * No information must go out of a web application (e.g. external links must
> >   not be followed, no requests from the client-side code)).
> This would rather break e.g. webmail, wouldn't it? What happens if
> someone sends me an HTML email with links in?

Hmm, good point. It's a problem that needs to be resoloved somehow. It
would certainly break embedded images and I think that's a good thing.
There are two problems here. One, making it clear to the user when the
content is not part of the application. This can be solved. Preventing
information leak, however, may be difficult to solve.

> > No information must go into
> > a web application.
> I don't understand what you mean by that, as the obvious understanding
> makes no sense. :-)

You are right, sorry about that. I meant to say Cross-Site Request
Forgery must not be allowed. E.g. if you are logged in at your bank's
secure web application you don't want a rogue web site you happen to
be visiting at the same time (using your browser, in another window)
to initiate a bank transfer on your behalf. Some call this session
riding, and there are other names for it.

> > We may need to have designated input and output
> > areas. We may
> > allow the application to screen requests before allowing them.
> Again, I don't understand what you mean by this.

To solve the CSRF problem we can't simply reject all links into a
secure web application. The idea is to have the descriptor list the
URIs within the application that can be linked to freely.
Alternatively, such URIs can be subject to a screening process (on the
server), which can determine if they are safe or not. A similar
concept can be applied to outgoing links.

> > * Separate cookies from session tokens, produce a new state maintenance
> >   RFC that is non-ambiguous. Session tokens are not to be accessed by
> >   client-side code. They mustn't be visible to the end user either. Make session
> >   tokens worthless by separating authentication from session management (e.g.
> >   require authentication to take place for every request).
> Content-Restrictions also solves this problem.

That can be debated. But since I didn't not present my ideas in
opossition to your Content-Restrictions proposal let's just stick to
the main topic of this thread.

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