Re: [Zope-dev] question: forcing https for authentication
Oliver Bleutgen wrote at 2003-1-17 18:02 +0100: > Dieter Maurer wrote: > > You might use a "SiteAccess" access rule. > > Dieter, thanks for the suggestion. But I don't see how SiteAccess could > help me here, maybe I'm missing something. > > Basically, what I want to do is to prevent zope from ever sending a > unauthorized response to a clear text http request, In your AccessRule, you can customize the the "_unauthorized" method of the RESPONSE object. The AccessRule must be implemented in an External Method in order to be able to change "RESPONSE._unauthorized". You can look at Cookie Crumbler. It uses a similar technique to prevent an Unauthorized response and rather display its login form. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] question: forcing https for authentication
Dieter Maurer wrote: You might use a "SiteAccess" access rule. Dieter, thanks for the suggestion. But I don't see how SiteAccess could help me here, maybe I'm missing something. Basically, what I want to do is to prevent zope from ever sending a unauthorized response to a clear text http request, instead it should send a redirect to a https://* URI, which would then send the unauthorized response, so that the browser dialog for basic authentication would only be trigger on a secure connection. I don't know where inside zope I could implement such a hook, that's why I posted here. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] question: forcing https for authentication
> And it's clearly worse performance wise for the typical use case, > because you now get a load of rewrite stuff for any URI which has to > be processed. Using mod_ssl the following works pretty well: SSLRequireSSL No rewrite or mod_rewrite overhead. You simply get a 403 if you don't use https. Dunno if thats an option for you but its something to think about. > All these complications and administrative burdens alone lead in effect > to insecurity. I'll buy that, but I don't have a good way to fix it. The z object hierarchy just isn't as easy to secure as a filesystem. > The example code I posted was more or less to illustrate my intention, > if I'd know where to implement such a hook, I'd probably try to make it > more flexible. Make it dependend from a startup flag, and check for a > magic attribute in the acquisition chain perhaps, which prevents the > redirect. Also allow for redirects to a different host. Well somebody mentioned Access Rules ... frankly I'm not sure what that buys you really, the problem seems to be its very difficult to classify what needs to be protected and what doesn't without trodding on somebody elses namespace or creating something overly fragile. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] question: forcing https for authentication
Jamie Heilman wrote: Well its true you can't prevent users from compromising their credentials, but you can prevent users from coming in the wrong door, as it were. I'm not clear on which one you really hope to accomplish, though from your proposed modifications it looks like the latter. Preventing users from compromising their creds can only be effectively done through education. For example, even if you used client certificates (which, afaik, are only used once an encrypted channel has been established) instead of basic auth there's nothing to stop a user from giving their cert and any requisite ancillary usage information (like the passphrase to decrypt it) to somebody else. Granted. I indeed want prevent users from coming in the wrong door. And it would really help if there wasn't a wrong door at all - therefore my question ;). The only ideas I have to tackle this without modifying zope itself are - customize all pages which need authentication to check for "https://"; in one of the relevant REQUEST attributes and do a redirect if not. - use apache with some magic to trigger redirection if it encounters authentication headers in the request. - use apache with some rewrite magic trigger redirection when a substring like "manage" is found in the request. These alternatives are neither elegant, nor really secure. I would agree the first two aren't sane, the third however is as good and as secure as you're going to get. Techniques for accomplishing it have been discussed on the zope list before and are undoubtedly in the archives. The mods you've posted with respect to guarding the WWW-Authenticate header aren't likely to work, and certainly wouldn't be flexible enough to allow, for example, mandating SSL usage for all /manage* requests while allowing clear-text basic auth for other restricted areas. Apache rewrite rules OTOH are flexible enough to allow this. I'm unclear as to why you consider it to be insecure, care to elaborate? The third alternative is indeed secure compared to the other two, in that it prevents plaintext credentials from going over the wire - as long as you remember to use always names like manage*. It's factually more insecure than my idea in that even ZMI's methods can be accessed with mangled names (e.g. http://server/manage/index_html). It's cumbersome because newly installed products always have to be checked for the method names. It's shaky, because if your filtering is too broad, better don't give the "corporate management profile" page an intuive id ;). And it's clearly worse performance wise for the typical use case, because you now get a load of rewrite stuff for any URI which has to be processed. All these complications and administrative burdens alone lead in effect to insecurity. The example code I posted was more or less to illustrate my intention, if I'd know where to implement such a hook, I'd probably try to make it more flexible. Make it dependend from a startup flag, and check for a magic attribute in the acquisition chain perhaps, which prevents the redirect. Also allow for redirects to a different host. cheers, oliver ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] question: forcing https for authentication
Oliver Bleutgen wrote at 2003-1-16 15:42 +0100: > One thing that bothers me is that I cannot reliably (as in "in a generic > way which always works") prevent users from sending their authentication > unencrypted. > The only ideas I have to tackle this without modifying zope itself are > > - customize all pages which need authentication to check for "https://"; > in one of the relevant REQUEST attributes and do a redirect if not. > - use apache with some magic to trigger redirection if it encounters > authentication headers in the request. > - use apache with some rewrite magic trigger redirection when a > substring like "manage" is found in the request. You might use a "SiteAccess" access rule. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] question: forcing https for authentication
Oliver Bleutgen wrote: > One thing that bothers me is that I cannot reliably (as in "in a generic > way which always works") prevent users from sending their authentication > unencrypted. Well its true you can't prevent users from compromising their credentials, but you can prevent users from coming in the wrong door, as it were. I'm not clear on which one you really hope to accomplish, though from your proposed modifications it looks like the latter. Preventing users from compromising their creds can only be effectively done through education. For example, even if you used client certificates (which, afaik, are only used once an encrypted channel has been established) instead of basic auth there's nothing to stop a user from giving their cert and any requisite ancillary usage information (like the passphrase to decrypt it) to somebody else. > The only ideas I have to tackle this without modifying zope itself are > > - customize all pages which need authentication to check for "https://"; > in one of the relevant REQUEST attributes and do a redirect if not. > - use apache with some magic to trigger redirection if it encounters > authentication headers in the request. > - use apache with some rewrite magic trigger redirection when a > substring like "manage" is found in the request. > > These alternatives are neither elegant, nor really secure. I would agree the first two aren't sane, the third however is as good and as secure as you're going to get. Techniques for accomplishing it have been discussed on the zope list before and are undoubtedly in the archives. The mods you've posted with respect to guarding the WWW-Authenticate header aren't likely to work, and certainly wouldn't be flexible enough to allow, for example, mandating SSL usage for all /manage* requests while allowing clear-text basic auth for other restricted areas. Apache rewrite rules OTOH are flexible enough to allow this. I'm unclear as to why you consider it to be insecure, care to elaborate? -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] question: forcing https for authentication
One thing that bothers me is that I cannot reliably (as in "in a generic
way which always works") prevent users from sending their authentication
unencrypted.
The only ideas I have to tackle this without modifying zope itself are
- customize all pages which need authentication to check for "https://";
in one of the relevant REQUEST attributes and do a redirect if not.
- use apache with some magic to trigger redirection if it encounters
authentication headers in the request.
- use apache with some rewrite magic trigger redirection when a
substring like "manage" is found in the request.
These alternatives are neither elegant, nor really secure.
So I have skimmed through zope's (2.5.1) source and wonder if modifying
HTTPResponse could work:
Change
def _unauthorized(self):
realm=self.realm
if realm:
self.setHeader('WWW-Authenticate', 'basic realm="%s"' % realm, 1)
to
def _unauthorized(self):
if spam[0:5] == 'https': # I wish I would know what to put here
realm=self.realm
if realm:
self.setHeader('WWW-Authenticate', 'basic realm="%s"' % realm, 1)
else:
self.redirect('https:' + spam[4:],lock=1) # or should we use
setHeader?
My questions:
Is _unauthorized always called when authorization is needed, or are
there more points which might set that header?
Can I get at the information I need to know if the request was via https
at this point (i.e. the spam thing) or is there a better place in zope
to do something I described?
Will redirection work here or might something overwrite the headers
later on?
Is it possible to implement this via a monkey patch (or whatever this is
called)?
Thanks,
oliver
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
