[WEB SECURITY] Web security improvement ideas

Ivan Ristic ivan.ristic at gmail.com
Wed May 25 07:45:02 EDT 2005

Several months ago I promised to send my ideas for web application
security improvement to this list. Please note that I am not claiming
these are all my ideas. While some of them are, many of these have
been proposed elsewhere and I picked them up over the years. I am
posting them here now with hope they will be of use to others.

With some more work the proposed changes could help us with XSS,
session hijacking, CSRF, and phishing. I think the improvements are
entirely feasible, although realising them is no small task. The real
question in my mind, though, is whether these improvements are
sufficient to "solve" the problem of web security in its entirety. (Or
at least be future-proof, i.e. compatible with future improvements
that may be required.)

So here they are:

* Introduce a new concept called "Secure Web Application". The main purpose of
  this is to make it possible to break backward compatibility.

  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.

  The remaining ideas apply to Secure Web Applications only.

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

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

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

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

* Design a mechanism for explicit log-out. And a mechanism for session timeout
  (in the browser). Delete all session information after it is terminated.

* 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)). No
information must go into
  a web application. We may need to have designated input and output
areas. We may
  allow the application to screen requests before allowing them.

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

  [Note: With some effort it is already possible to tie
  in session tokens to SSL session ids for added protection. But this is
  not portable, and I don't think SSL should be involved with session
  management anyway.]

This idea is not related to the Secure Web Application concept:

* Enforce strict web application interfaces on the web server level. Every
  application should be accompanied by a descriptor of some kind, to
  specify exactly what is allowed and what not. For example, it should
  allow the application to specify which requests it is willing to
  accepept, parameter names, and types. Naturally, this descriptor should
  not be made publicly available.

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