[WEB SECURITY] Web security improvement ideas
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
>>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
>>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