Forum OpenACS Development: Re: ETP Subnavbar Application commited

Collapse
Posted by Jade Rubick on
Can the support for <include> tags be optional?

The reason I say this is because there are some serious security implications of allowing people to execute template code. If you have access to the template level, that's quite a security risk. <% rm /tmp/* %> is a rather benign example..

It would be pretty easy to make this optional, and include a disclaimer that if you enable templating support, that you're compromising in security.

Granted, anyone with HTML access can hack your system too. But it's just so much easier with templating level access.

At least that's my understanding of it. Perhaps I'm wrong?

Admin level access would let you change the parameters, but create, write, and read levels would not, right?

Collapse
Posted by Malte Sussdorff on
I totally agree with you. Working include tags are a big risk. This is why I only put the switch into the subnav application and nowhere else. But having a parameter to turn it on / off would be a good thing as well, agreed.
Collapse
Posted by Jade Rubick on
Can someone commit to fixing this? This is a security hole, and even though I'm very happy about the new functionality, I think this is a security problem big enough that I would call it a blocking security bug. I wouldn't choose to deploy this on my own site, unless I have the option of turning it off (and by default it should be off I think)
Collapse
Posted by Malte Sussdorff on
Shall the parameter be Application, ETP or subsite-wide? If you say application specific, then I will upload a new subnavbar without <include> functionality. If you say ETP wide, I would ammend all the current ETP applications to make use of that parameter. And last but not least, if we make it subsite-wide, I would be looking into adding this to the weblogger (if it could be done easily). Someone else might then go off and add it either to the richtext widget or create a new widget type or manually edit this in each package.