[WEB SECURITY] Web security improvement ideas

Gervase Markham gerv at gerv.net
Fri May 27 05:18:42 EDT 2005

Ivan Ristic wrote:
>>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.

The descriptor is unlikely to be the same for every page in the web 
application - at least, if you want the best protection against 
cross-site scripting.

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

There are but, as you will know, not everyone implements them. At the 
moment, webservers are cheap, interchangeable, throwaway components. You 
are greatly increasing the work and cost involved in running one.

I really think your approach here (with respect to certs) is not 
practical, doesn't fit with the structure of PKI (for example, 
certificate revocations), and doesn't usefully solve any problems. I'm 
sure people with more knowledge of SSL than me would be able to 
elaborate further.

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

Has it ever happened? Hey, if it did, we might get $1000 from GoDaddy:

What happens if your new layer of security fails completely? Surely we 
need a third layer for that case?

>>>or tell me that I've arrived at a completely new
>>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.

There is no way you can avoid having a user take some action (even if 
it's just moving their eyes) to make sure they are in the right place, 
because the definition of "right place" is solely in the user's brain. 
The browser cannot accurately determine it.

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

Except that if I've been logging into my bank using my browser's 
Digest-Auth UI for months, and suddenly I get asked to type my password 
into a web page instead, I should be suspicious. If I'm not, I'm 
probably the sort of person who types my CC number into any web form 
that asks for it anyway.

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

This particular item has historically been managed by servers. Getting 
clients to manage it as well involves a great deal of upheaval and work 
- defining new standards, implementing them, getting web apps to support 
them. It seems to me that there are much more productive things to work 
on to improve security at the client.


The Web Security Mailing List

The Web Security Mailing List Archives

More information about the websecurity mailing list