[Zope-dev] manage_form_title patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
|
| We are protecting ourselves from nasty URLs written by anyone on the web.
| Because DTML is so implicit, it is conceivable that an URL like the
| following might kill your site (or worse!):
|
|
http://zope.example.com/?title=document.location=/Control_Panel/manage_shutdown
|
| For a black hat to exploit your site, he only needs to convince you to
| follow the link. This is what is known as a cross-site scripting bug and
| it's a widespread problem for all dynamic web servers like Zope. People
| are really concerned about it. The only cure is to HTML-quote by
default.
| FWIW:
|
| http://www.cgisecurity.com/articles/xss-faq.shtml
|
| Shane
The affixed patch makes it impossible to call manage_form_title
directly, and thus elimates xss attacks on it.
This method (and probably loads more) wasn't designed to be public, but
inherited this feature by virtue of being implemented as DTML.
Can someone please check and apply this patch (and back out the patch
html-quoting the form-title on manage_form_title.dtml) :)
TIA, Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.3.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Comment:
iD8DBQFACk1pCfroLk4EZpkRAtt/AJ9dm/I41iFTgsmtgeBUNN8B5Le8RgCfX9uz
vMqNG+w+QM8ioj1lENj/3q4=
=4Ukw
-END PGP SIGNATURE-
--- App/Management.py Sun Jan 18 19:43:55 2004
+++ App/Management.py.save Sun Jan 18 19:30:07 2004
@@ -173,14 +173,11 @@
manage_page_header=DTMLFile('dtml/manage_page_header', globals())
manage_page_footer=DTMLFile('dtml/manage_page_footer', globals())
-_manage_form_title =DTMLFile('dtml/manage_form_title', globals(),
+manage_form_title =DTMLFile('dtml/manage_form_title', globals(),
form_title='Add Form',
help_product=None,
help_topic=None)
-def manage_form_title(self, *args, **kw):
- return self._manage_form_title(self, *args, **kw)
-
-_manage_form_title._setFuncSignature(
+manage_form_title._setFuncSignature(
varnames=('form_title', 'help_product', 'help_topic') )
manage_form_title__roles__ = None
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py
Dieter Maurer wrote: Jim Fulton wrote at 2004-1-16 18:54 -0500: ... For security checks, the accessed object should be the driving factor and not the particular way the access is made. Well, sorry, that's not what this is about. We are talking about what to do when accessing objects without roles. The ability to take the name into account is a feature that only makes sense for named, ie attribute access, imo. "item" is a blurred term in Python: As you know, it refers both to sequences (indexed via integers) and mappings (indexed via something hashable; often a string). I don't see this as blurred at all. A sequence is, mathematically, a special case of a mapping. When some mechanism checks whether access should be granted to individual items in a mapping, this mechanism will (almost surely) need to know the key used in the access -- and I do not see any reason why it should not be informed about the key. I question whether there is a need to check "whether access should be granted to individual items in a mapping". I suggest that such flexibility makes the security system needlessly complex. I do not argue that the handler registered with "setDefaultAccess" should be used for "__getitem__" access checking. Cool However, when it is called (as it seems to be the case), then it should be called consistently and provide as much information as useful -- this includes information about both arguments to the "__getitem__" method. Ah, so you are arguing that the handler should simply not be called for item access. I can buy that. I don't think that would make Stuart happy though. :) Even more essential for security related issues: A precise description when what security related functions are called with what arguments. The current state in this respect is far from optimal. Special points of my concern: I assume that you are refering to the security policy. * I never saw a description of the difference between the "accessed" and "container" parameters to "validate". * I never saw a description for the three way outcome of "validate": "0", "1" and "raise Unauthorized". Why in hell is "unauthorized" encoded sometimes as "return 0" and sometimes as "raise Unauthorited". Looking at the code, I see that "accessed/container" has to do with this destinction. However, as "accessed/container" is unspecified, this does not clarify much. These are valid points. This should be documented much better than it has been. I'll note that both of the things you ask about relate to no-longer used features of the security policy. I'll make an attempt at a brief explanation: - The *original* reason for the accessed and validate parameters was to permit the distinction between acquired and non-acquired attributes. As a comment in the security policy code notes, we no-longer pay any attention to the accessed argument. - The *original* use for the 0 return value from the security policy was to suggest that, although access to the value provided was unauthorized, the application might provide a different value that would be. This was to support a questionable feature of trying to acquire another value of the first value found through acquisition was unauthorized. The current Zope security policy never returns 0. Much of the complexity in the Zope 2 security policy has to do with: - The fact that the security system is based on looking at assertions for values, and - The fact that we can't make assertions on immutable values (e.g. strings). Certainly, you have to think about how you provide access to data. Lots of data we provide access to has no security assertions of it's own. Maybe, we should change this for Zope 3? In Zope 3 (and, I hope 2.9), it will be easier to make security assertions about things you can't make assertions about now. The fundamental change in Zope 3 is that we make assertions about *names*, not values. This makes it possible to talk about access to attributes whose values are strings. Essentially, we are placing the resytictions on the *access*, not the values. It would have been possible for Zope 2 since a long time -- but tightening security has high risk to break many applicitation (as the latest security fixes demonstrated again). A mistake in Zope 2, we've made the mistake of trying to provide backward compatability at almost any cost. This has led to parts of the framework being far more complicated than it should be. In the future, we've got to do a better job of managing change so that we can clean things up. Think of accessor methods that return data. If data needs to be protected, you need to think about the access methods you provide. In the future, item access will work like this: You will be able to protect __setitem__ operations. Once someone can use setitem, they can access any key. The value stored with that key may have pretections of it's own, or not. That's a matter of application des
Re: [Zope-dev] CVS Head: "Error Value: iterable argument required" when adding objects
Jeremy Hylton wrote at 2004-1-17 17:39 -0500: > ... "umask" setting ... >they only >do it when a sysadmin configures zdaemon to run with the --umask >argument. That's not what the "zdaemon" documentation (as distributed with Zope 2.7b3) says: I read there: "zdaemon" sets the umask to "077" (preventing access by group and other) when it starts a program as a daemon. One may want that the group should have more rights. Therefore, someone suggested an "umask" option to control this "zdaemon" behaviour. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Security audit introduced problem in PageTemplates/Expression.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/01/2004, at 10:34 AM, Jim Fulton wrote: I I'm pretty sure that I can redo the way we protect dictionaries and lists so that we can provide backward compatability. If I can do this, I will, because backward compatability *is* important, especially for bug-fix releases. This is done and checked into the Zope 2.7 branch (Zope-2_7-branch). Stuart, can you try this out and make sure that your application works as it did before? All appears to be working as before. If this is definitely deprecated, I'll note that in AccessControl.py. I don't have a problem with deprecating this feature if it makes the Zope code saner - I was only using it because it was there and did what I wanted. I don't particularly like the idea of this mechanism working for getattr access but not for getitem access. I've always tended to stick with using getitem over getattr, partly as a holdover from when it was incredibly painful to mix getattr overrides with ExtensionClass, and partly because you are less likely to recursively shoot yourself in the foot. Indeed - an argument could be made for deprecating getattr in favor of getitem, as the latter could make use of Unicode keys if Zope's traversal mechanisms were updated to cope. - -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAC2d1AfqZj7rGN0oRAjPWAJ0VHsN8Rptk21xf90EyXTk5abgWiACeKZXM l6yznxwTidlY2vooA9b+o0s= =xCpW -END PGP SIGNATURE- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 2.7:contradiction btw port-base and server section in config ??
Hi there, I find two sections in 2.7's config file contradicticnorary. I therefore assume I did not grasp them: with the key port-base I can define at what addres the different servers run. The same I can (must ?) do defining the various servers: #valid keys are .. adress 8080 which one of the rules? I have the impression that for http port-base gains, for ftp the later (since I have not yet ftp working with 2.7) Robert ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
