Bobo-Exception-.. can produce rfc non compliant headers in response.
Yo, in case of an exception, the following headers, can produce non compliant HTTP response headers. Bobo-Exception-File Bobo-Exception-Type Bobo-Exception-Value Especially the Bobo-Exception-Value header, which is a chopped off version of the body of the response, is a cause of problems. fe -------------- included example ----------------- Bobo-Exception-Value: <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card> <p -------------- /included example ---------------- Normally, your browser doesn't barf on this, but browsers on small devices (like mobile phones) and their gateways are way more picky :( I have more than one problem with these headers: 1) most important: unpredictability of the RFC compliance. not a good thing. 2) security related: they give out way to much information to be confortable with. a client doesn't have any business with the absolute path to your zope install (Bobo-exception-File) and you even get these even when not running with the -D option. Although not enough info to hack/crack/whatever the machine/server it gives a hacker something concrete to work with. 3) usefulness: what do you gain from having these headers anyway? you have the error log on server side that contains the same information in another form. Is there still anybody out there who uses this ? if not, it's better to throw the whole thing out of the codebase, no ? Romain.
<snip examples of bad bobo-* headers>
I have more than one problem with these headers:
1) most important: unpredictability of the RFC compliance. not a good thing.
2) security related: they give out way to much information to be confortable with. a client doesn't have any business with the absolute path to your zope install (Bobo-exception-File) and you even get these even when not running with the -D option.
Although not enough info to hack/crack/whatever the machine/server it gives a hacker something concrete to work with.
3) usefulness: what do you gain from having these headers anyway? you have the error log on server side that contains the same information in another form.
Is there still anybody out there who uses this ? if not, it's better to throw the whole thing out of the codebase, no ?
This bit of black magic supports the ZPublisher.Client module, which is an rpc-like mechanism that pre-dates xml-rpc, SOAP, etc. I'm not sure how to gauge how many people may still use it :( That said, I think the issues can be fixed without necessarily throwing it out. I think if we: - escape or otherwise make the exception value header-compliant - remove the leading path on the exception-file (so you would only see 'something.py' ...then that would resolve these (legitimate) concerns. Thoughts? Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
<snip examples of bad bobo-* headers>
I have more than one problem with these headers:
1) most important: unpredictability of the RFC compliance. not a good thing.
2) security related: they give out way to much information to be confortable with. a client doesn't have any business with the absolute path to your zope install (Bobo-exception-File) and you even get these even when not running with the -D option.
Although not enough info to hack/crack/whatever the machine/server it gives a hacker something concrete to work with.
3) usefulness: what do you gain from having these headers anyway? you have the error log on server side that contains the same information in another form.
Is there still anybody out there who uses this ? if not, it's better to throw the whole thing out of the codebase, no ?
This bit of black magic supports the ZPublisher.Client module, which is an rpc-like mechanism that pre-dates xml-rpc, SOAP, etc. I'm not sure how to gauge how many people may still use it :(
That said, I think the issues can be fixed without necessarily throwing it out. I think if we:
- escape or otherwise make the exception value header-compliant
- remove the leading path on the exception-file (so you would only see 'something.py'
...then that would resolve these (legitimate) concerns.
Thoughts?
making the headers compliant and removing the leading path would solve the problem, but would probably break the rpc-like mechanism you talk about anyway, no ? I would fix/remove this myself (<10 minutes of work) but I don't have CVS write access, and you/we first need to decide what is most appropriate: - modify the headers to make them compliant and remove sensitive date - remove the Bobo-Exception-... headers completely. Romain.
making the headers compliant and removing the leading path would solve the problem, but would probably break the rpc-like mechanism you talk about anyway, no ?
no. :)
I would fix/remove this myself (<10 minutes of work) but I don't have CVS write access, and you/we first need to decide what is most appropriate:
Ok, for those interested, here's what I've done for 2.6.2 and 2.7 : - Any leading path info on the bobo-exception-file header is stripped - The bobo-exception-value now *always* says: "See the server error logs for details", to avoid inadvertantly exposing other things or producing arbitrarily chopped output that could confuse things like mobile device gateways. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
making the headers compliant and removing the leading path would solve the problem, but would probably break the rpc-like mechanism you talk about anyway, no ?
no. :)
I would fix/remove this myself (<10 minutes of work) but I don't have CVS write access, and you/we first need to decide what is most appropriate:
Ok, for those interested, here's what I've done for 2.6.2 and 2.7 :
- Any leading path info on the bobo-exception-file header is stripped
- The bobo-exception-value now *always* says: "See the server error logs for details", to avoid inadvertantly exposing other things or producing arbitrarily chopped output that could confuse things like mobile device gateways.
Splendid. thank you. Romain Slootmaekers.
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
Ok, for those interested, here's what I've done for 2.6.2 and 2.7 :
- Any leading path info on the bobo-exception-file header is stripped
- The bobo-exception-value now *always* says: "See the server error logs for details", to avoid inadvertantly exposing other things or producing arbitrarily chopped output that could confuse things like mobile device gateways.
Yay! Chris
--On Mittwoch, 23. April 2003 9:31 Uhr -0400 Brian Lloyd <brian@zope.com> wrote:
if not, it's better to throw the whole thing out of the codebase, no ?
This bit of black magic supports the ZPublisher.Client module, which is an rpc-like mechanism that pre-dates xml-rpc, SOAP, etc. I'm not sure how to gauge how many people may still use it :(
+1 to kick it for 2.7 where there are no complains and cries from people complaining. -aj
Andreas Jung wrote at 2003-4-24 12:52 +0200:
...
This bit of black magic supports the ZPublisher.Client module, which is an rpc-like mechanism that pre-dates xml-rpc, SOAP, etc. I'm not sure how to gauge how many people may still use it :(
+1 to kick it for 2.7 where there are no complains and cries from people complaining.
-1 We use it and find it much easier than the alternatives. Dieter
Chris Withers wrote at 2003-4-25 15:38 +0100:
Dieter Maurer wrote:
-1
We use it and find it much easier than the alternatives.
What about it do you find easier to use?
XML-RPC is extremely fragile with respect to the data types and the allowed characters in strings. Urlib does not do the automatic type encoding I estimate with ZPublisher.Client. Dieter
participants (5)
-
Andreas Jung -
Brian Lloyd -
Chris Withers -
Dieter Maurer -
Romain Slootmaekers