[
Lists Home |
Date Index |
Thread Index
]
> Note that the password is *not* transmitted in the URL. The server
> requests the password using standard HTTP authentication mechanisms
> and the client provides it in the standard way.
Then my requirement of limited exposure isn't met. Even worse, if *any*
packet is stolen, then my password is exposed. The only way to prevent
this is to use SSL for all traffic, which is not always a feasible,
or even reasonable, trade-off.
> Similarly other
> information that is often stored in cookies--shopping cart contents,
> path through a site, time of login, etc.--also need not be stored in
> the URL. The server maintains this information as it does even with
> cookies, at least in a secure system) and displays it to the user in
> the content of the page. However, it need not show up in referrer
> logs, browser location bars, and other such insecure places.
I don't understand how you could do this. Can you explain? The
client doesn't need the time of login, the server does. I don't see
what is the point of putting it in a clickable URL that the client could
fetch. Who cares if the client ever fetches it?
> But for each
> different resource, there should be at least one URI. Cookie based
> sites fail this test.
Only on those sites that use cookies wrong. I assume you mean the
kind of site that never changes the URL in the location bar, but
instead stuffs the "real" URL in the cookie and returns a bogus
Location header or some such. That's bad and broken. It indicates
that the site is doing things wrong, not that cookies are wrong.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
|
