I have been keeping a list of web security improvement ideas for some time now. It's a list that does not contain only my ideas but thoughts I picked up from others over the years. I have been showing the list to others lately, so I thought it would be a good idea to post it online too. I am posting it here straight from my notebook (you can probably tell from the lack of structure).
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.)
- 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 then 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 rest of the ideas presented here apply only to Secure Web Applications.
- 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. 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: http://www.w3.org/TR/NOTE-authentform.
- 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 (Secure Web Applications only, obviously).
- 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.]