[WEB SECURITY] Web security improvement ideas

Gervase Markham gerv at gerv.net
Thu May 26 05:08:21 EDT 2005


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

Any breaking of backwards compatibility is obviously undesireable, as 
I'm sure you would agree. Fortunately, I'm not sure it's necessary - see 
below.

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

> * 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/
It is backwardly-compatible with existing user agents.

> * 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? And I 
don't think SSL lets you send two certs and say "here's an old one for 
this site, and here's the new one I'll be using in future". 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?

What problem are you trying to solve with these suggestions?

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

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

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

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

> No information must go into
> a web application. 

I don't understand what you mean by that, as the obvious understanding 
makes no sense. :-)

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

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

Gerv

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



More information about the websecurity mailing list