My reply is going to be long, sorry. But i considered all of you, and you deserve a reply.
To lose features is not my goal. But we cannot exchange safety with features. Even if the risk could be appear to be reasonable, security experts and/or paranoids may spread a bad reputation on the software.
The reason why I came up with this thread is because I spent some time trying to stop all possible doors for malicious macros, and found no way to stay safe while keeping same features. But go on reading, because I found a decent solution.
@tsg
Calling people morons won't make the software safer.
Braces {} are valid chars in a file name.
Ok, {{delete}} will move to recycle bin, but as a feature. If someone wants to destroy a file can still use {{save}}.
Restricting paths can make it safer, but not safe. Think of an upload folder where i may delete all other files uploaded by others.
To detect if a VFS file was created on the same computer is a nice idea. I may save
all MACs on saving, and just search if any of them is available on loading. Sadly, an attacker could tamper the VFS file to make it contain a valid MAC address. Tho most of times an attacker won't know it, we cannot rely on the secretness of the mac address. So, I don't know a good way to detect if we are loading a file created elsewhere.
I think it is important to never include this folder in the vfs.
sure, because it contains passwords.
Some time ago, i proposed to allow in the advanced->diff-template section an option i named 'include path/filename' instead of having the diff templates in the data folders.
It's there, since long
If if the diff-template-option of hfs would implement such a feature, we could have all diff templates in the same secured sys-folder with a clear name (now we have to pay a lot of attention what the hell the diff template contains, as different templates have the same name!) and we could avoid the risk of uploading or erasing diff.templates.
that's a good idea. you'll find it in next beta.
@Unknown8063
just create your macros in the hfs folder, in a file "mymacros", then in the diff template you'll put just "mymacros", and it will be executed. The point is that an attacker hardly will have access to the hfs.exe folder, so it can be considered a trusted place.
@giant eagle
Yes, we may think of allowing macros in external diff tpl, since uploading them is forbidden by default. But this require some deep thinking to be sure there's no way to exploit it, and bacter's suggestion should be enough.
I suggest at this point also another macro: move -> {{move|filename|destinationfolder}}
You can use {{rename}} to get the same effect.
Still consider that even if HFS will be safe, a bad template can make it unsafe.
Example: {{delete|{{urlvar|filename}}}}
This will let people delete anything by entering the filename in the url.
That's because we are still considering the main template as a trusted thing.
It would be good we could warn people in case of possible threats, and ask for a confirmation, but i don't see a way. Do you?
@mars
yes, i think content of {{load}} should be protected.
I don't see the point in removing macros from {{save}} and {{append}}. Moreover i don't see why should {{section}} work with URLs. It just won't.
In the end, here is what i came to:
1. removed the <?tpl feature
2. macro-quoted the content of {{load}}
3. forbidden macros in:
A) %any-comment%
B) {{urlvar}} {{postvar}} and {{header}}
C) all filename-like %symbols%
D) saved .VFS files
Macro-quoting {{load}} will make easy to execute macros by using {{dequote|{{load|filename}} }}. This means no unexpected executions, and it requires you to be already allowed to use macros. Externals aren't.
I may think of using this same technique for comments, but i will only if users will really need this. Forbidding is somewhat safer than macro-quoting.
I had to remove <?tpl syntax because i couldn't prevent people of using single braces in filenames and other texts. It is much more acceptable to prevent double braces now, or {. .} when the new syntax will be activated.
Having the double syntax introduced with <?tpl made the work very complex and unsafe. Because it was easy for a template writer to have a %comment% inside a <?tpl block. Then, i should have prevented even single braces in comments, and filenames, etc. This is not very acceptable.
What really made the work feasible was removing the <?tpl syntax.
I'm not happy with removing it, because it required me hours to create it, but this should make HFS safe enough, again.
Now i have the new beta ready, and we'll see how it goes.