default configuration exposes template code and paths

[Steve Alexander]

The default configuration of Zope 3 has the very convenient feature that you can include a URL path step like /++debug++source/ to see comments in the page template source of the absolute paths of the templates on the filesystem, and /++debug++tal/ to see the source to the page template in comments in the rendered page template.

This debugging aid is enabled by default, and it isn't obvious how to turn it off. I expect most Zope 3 sites in production have this feature enabled. This is a marginal security risk on all systems (exposure of filesystem paths), and a security and confidentiality issue for non-open-source applications (exposure of page template source to the public that you didn't think would be exposed).

What should happen is that this feature should be disabled by default, and should be enabled only if someone explicitly turns it on.

A workaround is to put your Zope server behind something like Apache, and disallow requests with a URL that include the offending path steps.

[Philipp von Weitershausen (philikon)]

The ++debug++ namespace traverser is registered in zope.app.traversing/configure.zcml (last directive). I propose to add zcml:condition="have developer-mode" to this directive to prevent it from being loaded when developer mode is turned off. That should be the case for all production sites, really.

[Christian Theune (ctheune)]

+1 for philikons suggestion.

[Florent Guillaume (efge)]

+1

[Christian Theune (ctheune)]

Status: Pending => Accepted

 Supporters added: ctheune

Binding it to developer mode as suggested ...

[Christian Theune (ctheune)]

I'm checkin in the fix for 3.2, 3.3 and trunk. However, I don't see a reasonable way to test this. :(

Therefore I will not close this issue. If somebody could give me a hint on how to test this, I'd do it.

We might want to go for a disclosure now. I have not added a changelog entry though. The *default* configuration still exposes
the template code. Switching off the devmode disables access to
the ++debug++ namespace.

Comments?

[Steve Alexander (stevea)]

From the previous comment, I take it that Zope 3 is in development mode by default.

I think this is a mistake. It reflects an assumption that Zope 3 is mostly used to develop software and rarely used to deploy software. This might be true *today*, but surely it isn't something we want to be true long-term!

The principle use of Zope 3 libraries should be to develop new applications. Which is fine, beause that's just the libraries, and development mode has no bearing on that.

The principle use of Zope 3 instances should be for people to install already-written applications and simply run it. That's what the main use of PHP is. So, Zope 3 should ship with development mode disabled by default. The rare Zope 3 user who is a developer will follow the documentation and enable development mode. Like something like PHP.

Yeah, I know it doesn't reflect the Zope 3 userbase now, but if we want Zope 3 to be widely adopted and used as a base for cool pre-written software, we need to start thinking this way.

[Christian Theune (ctheune)]

> = Comment - Entry #7 by stevea on Jun 19, 2006 1:57 am
>
> From the previous comment, I take it that Zope 3 is in development mode
> by default.

That's right.

> I think this is a mistake. It reflects an assumption that Zope 3 is
> mostly used to develop software and rarely used to deploy software. This
> might be true *today*, but surely it isn't something we want to be true
> long-term!

Notice that Zope 2 ships with "debug mode" *off* by default. I think we should adopt the same strategy here.

> The principle use of Zope 3 libraries should be to develop new
> applications. Which is fine, beause that's just the libraries, and
> development mode has no bearing on that.
>
> The principle use of Zope 3 instances should be for people to install
> already-written applications and simply run it. That's what the main use
> of PHP is. So, Zope 3 should ship with development mode disabled by
> default. The rare Zope 3 user who is a developer will follow the
> documentation and enable development mode. Like something like PHP.

Yepp.

> Yeah, I know it doesn't reflect the Zope 3 userbase now, but if we want
> Zope 3 to be widely adopted and used as a base for cool pre-written
> software, we need to start thinking this way.

I'm totally with you. Maybe we should carry this to the mailinglist and get a general consensus on this topic. Making
the actual switch is easy. :)

[Christian Theune (ctheune)]

I discussed this with Jim and he agrees that this does not need to be confidential.

Two things that we came up with:

a) disable developer mode by default

b) log a warning when developer mode is turned on, maybe even put a
red banner in the ZMI to say "You're in developer mode. Don't use this in production." (or similar)

[Jim Fulton (jim-zope)]

Changes: submitter email, edited transcript, security_related unset

[Christian Theune (ctheune)]

Status: Accepted => Resolved

I changed defaults of the configuration schema and logging a warning on startup as discussed.

Fixed on 3.3 branch in revision 69553.
Fixed on trunk in revision 69554.

[Michael Haubenwallner (d2m)]

wee, this was not very helpful, my zope.conf is customized for a different port number, so got no update on 'svn up'.
you would have spared me half an hour of search if you just added:

- an entry in CHANGES.txt on the changed devmode default
- a better checkin message like
  "Make devmode be turned off by default."
  http://svn.zope.org/Zope3/trunk/zope.conf.in?rev=69554&view=rev

btw. /++help++/ should not hold a link to 'API Docs' with devmode off to avoid traversal errors -- or maybe access to ++apidoc++ could create a descriptive message instead of an error ?

[Baiju Muthukadan (baijum)]

so let me commit this to avoid confusion:
http://paste.plone.org/10291

[Baiju Muthukadan (baijum)]

Doc fix is commited in r69586,69587/69588

[Christian Theune (ctheune)]

For the record: The ChangeLog includes a message about this.

About the change in the UI: I don't like adding fineprint like this to the UI, as it tends to clutter it up. There should be a better way to communicate this. It's not like the actual behaviour changed, but just the default setting.

[Baiju Muthukadan (baijum)]

ctheune: what about adding a new method to z.a.applicationcontrol.interfaces.IRuntimeInfo
say `isDevmodeOn()` which will return True if `devmode` is on.
Based on this show the link to `++apidoc++`.

hmm..or is this more complex?

[Christian Theune (ctheune)]

This has other issues with the discoverability.

Here is an easy one: Keep the link active. Don't show the text. But based on the feature 'devmode' we put in a different registration for a page that says "This feature is disabled. To enable it, please enable developer mode for the Zope server."

[Philipp von Weitershausen (philikon)]

Status: Resolved => Accepted

+1 to ctheune's suggestion. I'm reopening this issue.

[Benji York (benji)]

-1 on the parenthetical note

[Christian Theune (ctheune)]

Status: Accepted => Resolved

Fixed on 3.3 branch and trunk.

The ++apidoc++ is now always available. If 'nodevmode' is set (i.e. developer mode is switched off), a message will be displayed the informs the user about apidoc's dependency on devmode.

[Michael Haubenwallner (d2m)]

Status: Resolved => Accepted

Uploaded: developermode.diff

here is a patch that adds getDeveloperMode() to IRuntimeInfo, thus allows to display the state of the current Developer-mode under 'Runtime Information'(/++et++process/index.html)

[Philipp von Weitershausen (philikon)]

I'm +1 on d2m's patch.

[Philipp von Weitershausen (philikon)]

d2m: Perhaps you can extend the application controller's (f)tests and include that in the patch. Then we can apply the patch right away.

[Michael Haubenwallner (d2m)]

Uploaded: developermodeandtest.diff

extended the patch to pass the tests

[Christian Theune (ctheune)]

Thanks Michael. I committed your patch to Zope 3.4.

[Dan Korostelev (nadako)]

The fix was released.