Tainted strings are new in Zope 2.6 to make it more difficult that cross scripting bugs slip in.
If you are lucky, there is an explicite conversion between a tainted string and a string. If not, you must make one in an External Method.
Thanks for your reply. I just found this thread about TaintedStrings: http://mail.zope.org/pipermail/zope-coders/2002-August/001598.html and my case was exposed there:
Passing a TaintedString value from a DTML template to other objects such as Python code, External Methods, Python Scripts, etc, may cause them to break because they did not anticipate a TaintedString object.
Actually my case it's really uncommon, but as you see it can happen: one of the users wanted to say that the dimmensions of something should be minor than 1 m, so he wrote "< 1 m". Then come that exception. One possible solution could be to convert all the "<" symbols to "<". But I was wondering if there is another way of dealing with this TaintedStrings (appart of disabling the check, off course). Regards, Josef
Josef Meile wrote:
One possible solution could be to convert all the "<" symbols to "<". But I was wondering if there is another way of dealing with this TaintedStrings (appart of disabling the check, off course).
Make sure the variable in question gets explicitly pulled from the correct dictionary in the REQUEST object. Personally I think REQUEST.get is a hallmark of horrible design anyway. Has anyone written a HTTPRequest replacement that gets rid of "get magic" entirely? I'm sure it would break a billion things, but I'd be interested in playing with it regardless. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Just do REQUEST.form.get('foo') instead of REQUEST['foo'] or REQUEST.get('foo') to avoid the string tainting magic. I don't agree that the REQUEST.get magic is a "hallmark of horrible design". I know I wouldn't want to go back to the days of Perl CGI, worrying whether something was in the query string or was form elements or in a cookie, in the environment, or wherever else. 99.9% of the time, I don't care. The .1 percent of the time that I do I can ask for it explicitly from the namespace I want. - C On Wed, 2003-04-16 at 15:53, Jamie Heilman wrote:
Josef Meile wrote:
One possible solution could be to convert all the "<" symbols to "<". But I was wondering if there is another way of dealing with this TaintedStrings (appart of disabling the check, off course).
Make sure the variable in question gets explicitly pulled from the correct dictionary in the REQUEST object. Personally I think REQUEST.get is a hallmark of horrible design anyway. Has anyone written a HTTPRequest replacement that gets rid of "get magic" entirely? I'm sure it would break a billion things, but I'd be interested in playing with it regardless.
-- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Also FWIW, you can disable the tainting behavior entirely by setting the envvar ZOPE_DTML_REQUEST_AUTOQUOTE to 0 in the shell before you start your Zope process. On Wed, 2003-04-16 at 15:53, Jamie Heilman wrote:
Josef Meile wrote:
One possible solution could be to convert all the "<" symbols to "<". But I was wondering if there is another way of dealing with this TaintedStrings (appart of disabling the check, off course).
Make sure the variable in question gets explicitly pulled from the correct dictionary in the REQUEST object. Personally I think REQUEST.get is a hallmark of horrible design anyway. Has anyone written a HTTPRequest replacement that gets rid of "get magic" entirely? I'm sure it would break a billion things, but I'd be interested in playing with it regardless.
-- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Jamie Heilman wrote at 2003-4-16 12:53 -0700:
Josef Meile wrote:
One possible solution could be to convert all the "<" symbols to "<". But I was wondering if there is another way of dealing with this TaintedStrings (appart of disabling the check, off course).
Make sure the variable in question gets explicitly pulled from the correct dictionary in the REQUEST object. Personally I think REQUEST.get is a hallmark of horrible design anyway.
Why do you think so? Dieter
Dieter Maurer wrote:
Jamie Heilman wrote at 2003-4-16 12:53 -0700:
Personally I think REQUEST.get is a hallmark of horrible design anyway. Why do you think so?
It flattens namespaces that don't have the same characteristics. This tends to catch programmers off guard and introduce bugs. If you have an 8k header limit defined in your HTTP server along with a 1M POST limit and then you use REQUEST.get() to grab a cookie value without taking into account that it could be 1M in length before you go to process it, bad things can happen. "This is one of the instances where you should use the exact dictionary," you say. Well sure, but what do you do when you've got interfaces built around REQUEST.get() magic that don't let you choose? Case in point, a RAMCache's aggregateIndex function blindly REQUEST.get()'s a list of manager defined variables. If you aren't careful this has some really really shitty security implications. It also changes the trust characteristics of the variables. A key-value pair provided by the server that the request has no inate ability to change, normally trustworthy, is degraded by getting placed into the grab order of REQUEST.get(). That alone isn't a bug, its just places the onus on the programmer to have a complete understanding of the implications of namespace flattening. I think its fair to say this improves the odds of programmer error, and before you disagree with me I'd like to point out that the HTTPRequest code concedes, and unfortunately has made a half-assed attempt at protecting the programmer from this invalid assumption; it strips all the well known, traditionally CGI, variables right out of the form namespace. Personally, I call that a bug. So did peterb when he filed issue 546. In short, if you want a function to do variable aggregation, thats OK, but its my believe that function shouldn't be sold to the masses as the 99% solution to all their data gathering needs; it should be the exception rather than the rule, it should offer a flexible way to include, exclude, and re-order the lookup rules on the fly, and there should be no default order--the order should be a mandatory argument, thus forcing the programmer into thinking about which namespaces are truely pertinent. -- 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
Jamie Heilman wrote at 2003-4-17 13:38 -0700:
Dieter Maurer wrote:
Jamie Heilman wrote at 2003-4-16 12:53 -0700:
Personally I think REQUEST.get is a hallmark of horrible design anyway. Why do you think so?
It flattens namespaces that don't have the same characteristics.
This tends to catch programmers off guard and introduce bugs. If you have an 8k header limit defined in your HTTP server along with a 1M POST limit and then you use REQUEST.get() to grab a cookie value without taking into account that it could be 1M in length before you go to process it, bad things can happen. "This is one of the instances where you should use the exact dictionary," you say.
Indeed. When you know the value must come in a cookie your would say so.
Well sure, but what do you do when you've got interfaces built around REQUEST.get() magic that don't let you choose? Case in point, a RAMCache's aggregateIndex function blindly REQUEST.get()'s a list of manager defined variables. If you aren't careful this has some really really shitty security implications.
Everything is REQUEST has security implications. With the exception of some elements in "REQUEST.environ", everything can be forged. Beside this, the application can know the expected interface (the control variable names used in respective forms) and form variables take preceedence over cookies (that are not local). Thus, cookies do not present a problem.
It also changes the trust characteristics of the variables. A key-value pair provided by the server that the request has no inate ability to change, normally trustworthy, is degraded by getting placed into the grab order of REQUEST.get().
At least the documentation says that "REQUEST.environ" lookup takes preceedence before other sources. "environ" is the source for the server defined keys you mention.
.... In short, if you want a function to do variable aggregation, thats OK, but its my believe that function shouldn't be sold to the masses as the 99% solution to all their data gathering needs; it should be the exception rather than the rule, it should offer a flexible way to include, exclude, and re-order the lookup rules on the fly, and there should be no default order--the order should be a mandatory argument, thus forcing the programmer into thinking about which namespaces are truely pertinent.
Acquisition is a much more drastic "namespace flattening" (as you call it) than the harmless merging of 4 individual dictionaries in REQUEST. I know, it can be dangerous but nevertheless I am very happy that it is is there and makes lots of my daily tasks much easier. I have much more trust in programmers than you seem to have. We are developping internet applications and (hopefully) not nuclear power plant controls, airflight control systems or such high rish applications. Therefore, ease of development is a valuable factor. Dieter
participants (4)
-
Chris McDonough -
Dieter Maurer -
Jamie Heilman -
Josef Meile