Re: [Zope-dev] Zope security alert and 2.2 information
Chris Withers wrote The problem is HTTP Basic Authentication caching the user's details until it gets told they've failed authentication for that realm...
.. and even then, if they've had a previous successful auth for a page, the browser will re-use the token. The only _real_ way to do it properly is to pass a token to the client, and use that token to reference their authentication information. That way, when they log out, you destroy the authentication information on the server side. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On 10 May 2000 09:10:02 -0500, Anthony Baxter wrote:
.. and even then, if they've had a previous successful auth for a page, the browser will re-use the token. The only _real_ way to do it properly is to pass a token to the client, and use that token to reference their authentication information. That way, when they log out, you destroy the authentication information on the server side.
Some browsers *do* only pass authentication info when the server requests it. We discovered this a couple of years ago when experimenting with the newly-developed domain authentication that I asked to be implemented in userfolders with Principia. Popular methodology was to pass the user through an authentication portal which triggered the client into establishing the site/ authentication action, and then reyling on the client to continue to send the authentication info even though the server objects weren't requiring it. This scheme didn't work with the clients which only sent auth. info when requested, so we made sure that all objects referenced the required authenticator objects at all times. Sites developed with this expectation that simple authentication portals are adequate can be quite trivial to bypass... It also became clear that I needed to thoroughly test all my sites with a browser which didn't automatically send auth info once 'portalled' as some of the failure modes were quite elaborate and almost impossible to determine without actual testing. Some were quite puzzling even though you were watching the failure occur.
On 12 May 2000, Kent Polk wrote:
Some browsers *do* only pass authentication info when the server requests it. We discovered this a couple of years ago when experimenting with the newly-developed domain authentication that I asked to be implemented in userfolders with Principia.
Unless I'm badly mistaken, the standard Zope management interface has a problem with this. My perception is that w3m is a browser that only passes auth info when requested. If I'm looking at a management screen, and I click on a link that takes me to 'manage_workspace' for that object, Zope responds as if I am not authenticated. If I explicitly type in the URL with 'manage_main', then I get the management screen. I'm *guessing* that manage_workspace somehow does not require 'view management screens' permission but 'manage_main' does. What are other browsers that have this behavior? I'd like to test my theory... If I'm right, is this a bug in Zope? --RDM
R. David Murray wrote:
On 12 May 2000, Kent Polk wrote:
Some browsers *do* only pass authentication info when the server requests it. We discovered this a couple of years ago when experimenting with the newly-developed domain authentication that I asked to be implemented in userfolders with Principia.
Unless I'm badly mistaken, the standard Zope management interface has a problem with this.
My perception is that w3m is a browser that only passes auth info when requested. If I'm looking at a management screen, and I click on a link that takes me to 'manage_workspace' for that object, Zope responds as if I am not authenticated. If I explicitly type in the URL with 'manage_main', then I get the management screen. I'm *guessing* that manage_workspace somehow does not require 'view management screens' permission but 'manage_main' does.
What are other browsers that have this behavior? I'd like to test my theory...
It was a while back and I don't have access to any of the browsers to test with now, but none of them had any trouble with the standard Principia (before Zope) management screens. The problems were encountered if you simply assumed that objects were requiring authentication, such as by passing them through an authentication portal which was only used to establish authentication and never used thereafter, and simply used AUTHENTICATED_USER to determine the status of authentication instead of just the name of the authenticated user. The results were that browsers which didn't automatically send authentication info were disallowed access, and you could reasonably easily bypass the server authentication mechanism if objects themselves didn't authenticate. Sorry that I don't have up-to-date info here, but I haven't had to develop any sites which require authentication since then. Sounds like you are possibly stating that when Zope was extended, it didn't continue to require that its management objects required authentication and simply relied on the value of AUTHENTICATED_USER to determine authentication. Is this correct? At the time I simply saw the problem as one of 3rd party software design. I.e. if you didn't build the site so its objects required authentication as appropriate, it wasn't Principia's problem, it was yours (or mine). I also believe the second issue isn't a problem with browsers which only send auth. info when requested. Relying on access procedures to ensure security is 'security by obscurity' and nothing more.
participants (4)
-
Anthony Baxter -
Kent Polk -
kent＠tiamat.goathill.org
-
R. David Murray