Templates - hints

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

Hockey wrote:By including a bunch of runtime checks, your not only adding bloat (which in most cases it would seem is not required) but your also fixing a problem at facevalue instead of *really* tackling the issue at the root.
Adding a bunch of checks to the compiler isn't going to cause much of a problem when it comes to performance. This is because the compiler only runs once for the initial compilation of the template. After that the only time the compiler is called is if the template file has changed in anyway.

After the initial compile the template engine itself is the only thing executing the precompiled template. As long as the template engine stays small and fast then everything is fine. For the most part the compiler itself doesn't have as big a restriction on performance because it is only run once to compile the template the first time it is accessed.

The bad thing about classes under PHP is how each variable you add to the class increases the memory footprint by a large amount. Far more than I ever would have expected. :) So keeping the variable usage low for the template engine is one of the primary concerns as well as making most of the functions that are used by the engine modular so they are only loaded when needed.
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

arborint wrote:
Roja wrote:PJ: Whether you feel its a risk or not doesn't change the facts. Given a template with embedded php tags (and the ones you currently offer for aatrade contain them), an admin using template-lite has two choices: Examine the entire template for risks, or accept the risk. With smarty, there is a third choice: Turn on security, and you are safe from that risk. That is why *I* feel your library isn't appropriate for BNT, and won't endorse it for situations where admins routinely do not examine templates line-by-line.
I think the flaw in this logic is that in your "third choice" for both libraries requires both Admin awareness and an Admin action. So an Admin unaware of the danger would have the same risk with either library. And an Admin aware of the problem would have a solution with either library (In both cases the recommendation is the same: install Smarty and set security=true). I think AKA Panama Jack agrees with you on the point that his library is currently not appropriate for cases where you want security=true -- so I don't believe there is an actual disagreement.
That's basically true. :)

As I indicated before most applications that use Smarty do not use any of the security features that are available. So both Template Lite and Smarty under most applications operate with the same amount of security. This means that the admin has to have over site of the web applicate and templates.

The only reason you would need to use the $security flag in Smarty is if you have given access to the template directory to others who are outside your control. Since most applications do not enable the security features of Smarty you can assume the authors expect the admin to maintain control over the template directories and not give access to untrusted outsiders.

As I said some of the missing features will be added in the future. I just have to find the time. Plus I need to create the smallest and fastest code possible to be able to continue calling the package a lighter version of Smarty. I have four different projects I am working on at the moment so I am spread a little thin. :?

As I said before if you are letting untrusted people access your template directory then stick with Smarty until the extra security features have been added to Template Lite.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

A (theoretical) discussion about TL security

Post by Roja »

[[edit]] It occurs to me we are seriously hijacking the original thread purpose. Would a mod like to split the topic, or clarify if we are clear to continue this branching?[[edit]]

Template-Lite allows templates - data - to execute commands. It does not offer any protection against hostile templates. It requires admins to TRUST all templates they install.

Ask yourself three questions:

1. Is there a risk? Yes. PJ recognizes that executing code can produce dangerous effects.

2. Is there a reasonable way to reduce that risk? Yes. The Smarty template engine offers security features which do exactly that. Template-Lite could port them.

3. Is there a reason not to do so?

The third is where the discussion is occurring. Thats important to note. No one is disagreeing that there is a risk. No one is disagreeing that there is a way to prevent it. They are simply arguing that the risk is already mitigated - by placing the responsibility on the admins.

Lets assume that the admin has taken the time to review every line of every template installed in his app (~15,000 lines in the latest AATrade, for each template). Lets also assume that he downloaded it securely, and verified it (with checksums), and didn't have a user install it.

In other words, lets assume the perfect situation exists.

What happens if the user input in your app, and in the template engine, passes executible code to the template?

Under smarty, with security enabled, nothing happens.

Under template-lite, the site is compromised.

Now, I posit that without the next paragraph, thats a flaw, and it deserves fixing. I'm not going to use a template engine without that security. But others feel otherwise, so the next paragraph is (apparently) needed to clarify the position they are endorsing.

What if there is already a method in both AATrade, and in Template-Lite that allows a user to pass data to the template engine, which the template engine executes?

Theoretically, of course.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: A (theoretical) discussion about TL security

Post by Christopher »

1. Is there a risk? If you don't let untrusted users access to your templates -- then no.

2. Is there a reasonable way to reduce that risk? Yes. Don't let untrusted users access to your templates. Or use Smarty.

3. Is there a reason not to do so? I believe that code size and performance are the raison d'etre for Template-Lite's existence, so Yes.

I am really not clear why you keep on about this. It is not as if there is no alternative that doesn't have the feature you want. If you want all the features of Smarty -- use Smarty. If you can accept fewer features because you want a lighter library -- use Template-Lite.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Template-Lite allows templates - data - to execute commands. It does not offer any protection against hostile templates. It requires admins to TRUST all templates they install.
Admins put a lot of trust in PHP files they download too. Why a different standard for templates? If they both come from the same source (presumably trusted) there's no difference. Templates do not forbid PHP, a template with PHP controlling the presentation logic is quite valid.
1. Is there a risk? Yes. PJ recognizes that executing code can produce dangerous effects.
We all recognise the risk - but it applies to untrusted parties in a scenario where such files are NOT the responsibility of an apps developers. I have templates in QS which are perfectly safe. If a user replaces them well, that's their choice. If they select a source I know nothing of it's still not my problem. I distributed a secure app - they made it insecure. Not me.
2. Is there a reasonable way to reduce that risk? Yes. The Smarty template engine offers security features which do exactly that. Template-Lite could port them.
If my templates are fixed entities, it's not my problem. Harsh but true. It's not my responsibility, it's not the library developer's responsibility, it's the user's.
3. Is there a reason not to do so?
Because I trust my own code not to mutate into a malevolent entity behind my back...:)
What happens if the user input in your app, and in the template engine, passes executible code to the template?
Your argument is flawed, this is an application security flaw. User input should be filtered and appropriately escaped by the developer. Since the Template includes executable PHP - that too is the responsibility of the developer. A valid security flaw - but not in the template library.
Under template-lite, the site is compromised.
...by the application developer, not the template engine.
What if there is already a method in both AATrade, and in Template-Lite that allows a user to pass data to the template engine, which the template engine executes?
Then AAtrade would have a security flaw, one caused by the developers failing to lock down their PHP code. I stress THEIR PHP CODE .

Try another scenario. Template Lite, bad boy that it is, refuses to escape template variables it is passed automatically. The app developer then fails (in error) to filter and escape some user input. It's assigned to a template, parsed and output. Users start complaining that a mysterious force appears to be deleting their account contents.

Who do we blame?

Template Lite for not escaping these obviously risky variables?
Or the developer who neglected to use that escape modifier provided in the template syntax?
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Re: A (theoretical) discussion about TL security

Post by Roja »

arborint wrote:1. Is there a risk? If you don't let untrusted users access to your templates -- then no.
As I said - there could be. Even with a trusted template, with a trusted admin, if there is a way to get input into that template, it will execute it. Thats a risk.
arborint wrote:2. Is there a reasonable way to reduce that risk? Yes. Don't let untrusted users access to your templates. Or use Smarty.
The latter does solve the problem. The first ignores other potential sources of danger.
arborint wrote:3. Is there a reason not to do so? I believe that code size and performance are the raison d'etre for Template-Lite's existence, so Yes.
So offer it as an optional plugin.
arborint wrote:I am really not clear why you keep on about this. It is not as if there is no alternative that doesn't have the feature you want. If you want all the features of Smarty -- use Smarty. If you can accept fewer features because you want a lighter library -- use Template-Lite.
Because people are arguing that there is no risk. There is a risk, and it does not go away in the perfect world of a trusted admin and a trusted template (nevermind the fact that neither is a secure solution to the problem).

Thats why I kept on.
Maugrim wrote:Under template-lite, the site is compromised. ...by the application developer, not the template engine.
And the template engine offered no alternative, no protection, and no management of that risk. Despite offering to execute data as code by default. Its default behavior has risk, and there is no direct solution offered by the template engine.
Maugrim wrote:Then AAtrade would have a security flaw, one caused by the developers failing to lock down their PHP code. I stress THEIR PHP CODE .
And with the principle of defense in depth, with the Smarty security features in place, its wouldn't cause a failure at the template engine layer. Thats a flaw in the template engine! Just because you can alternatively avoid the problem with { good admins, trusted templates, different template engines}, doesn't change the fact that it IS a flaw at the template engine level.
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Re: A (theoretical) discussion about TL security

Post by AKA Panama Jack »

Roja wrote:
arborint wrote:1. Is there a risk? If you don't let untrusted users access to your templates -- then no.
As I said - there could be. Even with a trusted template, with a trusted admin, if there is a way to get input into that template, it will execute it. Thats a risk.
Please explain how there could be a risk in the above scenario? From your response you are hinting that anyone entering information into the web page could execute something because of the template engine and that is patently false. It is one thing to claim there is a risk but it is quite another to claim it and give an example of said risk. So far you haven't been able to give a risk just hinted that there could be a risk.

It's like claiming you could be abducted by aliens if you ever leave your house wearing your normal clothes and not offering any proof how it could happen. You just claim even if you are vigilant and watch the sky, everything around you there may be a way aliens could still abduct you. So you really need to wear clothing with metal foil lining it to prevent the aliens from seeing you.

Please stop with the "I don't know how it could happen but I know it could happen." line of reasoning. It's not logically thought out or reasoned.
Roja wrote:
arborint wrote:2. Is there a reasonable way to reduce that risk? Yes. Don't let untrusted users access to your templates. Or use Smarty.
The latter does solve the problem. The first ignores other potential sources of danger.
That is total nonsense, especially from anyone claiming to be a Security Professional. There is no difference between not allowing untrusted users access to the template directory and not allowing untrusted users access to the webroot.
Roja wrote:
arborint wrote:I am really not clear why you keep on about this. It is not as if there is no alternative that doesn't have the feature you want. If you want all the features of Smarty -- use Smarty. If you can accept fewer features because you want a lighter library -- use Template-Lite.
Because people are arguing that there is no risk. There is a risk, and it does not go away in the perfect world of a trusted admin and a trusted template (nevermind the fact that neither is a secure solution to the problem).

Thats why I kept on.
There isn't a risk but you fail to see it for some reason. You seem to assume that someone who shouldn't have access to the template directory might get it. So why aren't you just as worried about someone who doesn't have access to the webroot getting access to it?
Roja wrote:
Maugrim wrote:Under template-lite, the site is compromised. ...by the application developer, not the template engine.
And the template engine offered no alternative, no protection, and no management of that risk. Despite offering to execute data as code by default. Its default behavior has risk, and there is no direct solution offered by the template engine.
If the application developer is inept enough to screw up his site through a template then he has probably screwed his site up far more writing the code for his application. Your line of reasoning just doesn't follow through logically.
Roja wrote:
Maugrim wrote:Then AAtrade would have a security flaw, one caused by the developers failing to lock down their PHP code. I stress THEIR PHP CODE .
And with the principle of defense in depth, with the Smarty security features in place, its wouldn't cause a failure at the template engine layer. Thats a flaw in the template engine! Just because you can alternatively avoid the problem with { good admins, trusted templates, different template engines}, doesn't change the fact that it IS a flaw at the template engine level.
It is NOT a flaw and never has been.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: A (theoretical) discussion about TL security

Post by Christopher »

Roja wrote:Because people are arguing that there is no risk. There is a risk, and it does not go away in the perfect world of a trusted admin and a trusted template (nevermind the fact that neither is a secure solution to the problem).

Thats why I kept on.
No, if all the templates are from a trusted source then there is no risk. But let's be clear that the risk we are talking about is about maliciously inserting PHP code into templates. If you want to extend the definition of risk to be any potentially insecure or malicious PHP code they there is always a risk -- even when not using either of these libraries.

The most ironic thing about this converstation is that AATraders and all other PHP programs that used Smarty were open to potential attack before 28-May-2006 because Smarty secure mode actually allowed code to be executed.

It is far worse to build your security on false premises than to know your risks and make choices to deal with them.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Re: A (theoretical) discussion about TL security

Post by Maugrim_The_Reaper »

And the template engine offered no alternative, no protection, and no management of that risk. Despite offering to execute data as code by default. Its default behavior has risk, and there is no direct solution offered by the template engine.
This is where I jump off the bandwagon... There are at least two separate risks being mentioned so far - user input, and PHP code in templates.

The first has nothing to do with a template engine flaw or error. The input should be filtered and escaped by the developer - they know the data, they determine what requires escaping. Yes, the template engine could hande this within the templates (giving the designer a say), and yay, it can. The "escape" modifier. Personally I prefer doing it manually, I pretty much escape everything without exception in the basis allowing exceptions allows mistakes.
The first ignores other potential sources of danger.
Name one, and provide an example (well, if PJ has no objections). This is unrelated to the originally posted "flaw".
And the template engine offered no alternative, no protection, and no management of that risk. Despite offering to execute data as code by default. Its default behavior has risk, and there is no direct solution offered by the template engine.
We really need to fine grain this whole debate... It's getting murky.

Risk 1: Template contains malicious code. Right?

Now where is the risk generated? The author of the template. The template engine cannot be the risk generator since it has been deemed to have no responsibility for screening PHP code within a template - it's blunt and true - it does not care. This is a documented difference from Smarty. The logical conclusion is that if an application developer fails to implement a method to mitigate any such risk, they have failed in securing their application. It's their job. Yes, it COULD be the template engine's job - but it's not. It parses, it compiles, it generates - the rest is not in its job description. It does its documented job - you can't blame it when it's accused of failing to do something. It'll just pull out its job description and throw a two finger salute.

It is not a Template Engine's job to second guess the developer - unless the developer wishes to be second guessed. Or have someone second guessed. For this very reason, Smarty is distributed with the security feature (feature - not required security) disabled by default. What you are claiming is that PHP in a template is wrong - more or less.

This is just plain wrong.
And with the principle of defense in depth, with the Smarty security features in place, its wouldn't cause a failure at the template engine layer. Thats a flaw in the template engine! Just because you can alternatively avoid the problem with { good admins, trusted templates, different template engines}, doesn't change the fact that it IS a flaw at the template engine level.
Your first sentence is entirely correct. The Smarty feature is a perfect example of defense in depth. However, such a measure should in most circumstances remain a redundant measure, as in never required. If I write a Template, with no PHP code, and use the Template-Lite library, and distribute my application - I fully expect such a feature NEVER TO BE REQUIRED. Having it would be a comfort blanket only. Pointless. I already have multiple layers protecting template use.

Such a measure does become a requirement (not simply a defense in depth measure) when the risk of a contaminated template being introduced into a system increases. Suddenly the template is out of my control, I'm not writing it, I'm not reviewing it, some guy down the road did. Using TL then would be crazy talk.

You could (and you seem to be) go so far down the paranoid street that you distrust the developers of an app and make it a requirement. What you're missing is that most of us assess that risk as negligible. If something goes wrong within the ranks of a project, I strongly doubt our templates are the hotspots.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

I've done my best here, and it only seems to be making things worse.

There is a risk. Whether its from an insecure template, or improper input validation, or directory compromise, or a dozen other issues, the template can (and in multiple realworld examples, does) get untrusted data. That data is then executed as php code.

Smarty offers a solution to that problem, and Template-Lite could port that solution. He's choosing not to at the moment, so I won't endorse TL as a secure solution.

Others are free to ignore the risks, push the responsibility for security onto input filtering, admin activity, and so on. I'm not nearly as cavalier.

I've brought up a risk (template engine executing code), and pointed to multiple situations that could turn that into a serious risk.

People wanted an explanation of my personal and professional choice not to use Template Lite. I've explained it. If you don't agree, thats your choice.

I want to note that this all stemmed from me making a choice which I mentioned on a development forum for a game, and on my blog, and I've been hounded and attacked both for not answering, and when I did, for being too secure in my decision making. If you don't want to know the answer, don't ask the question. :)

I take security very, very seriously. I do everything I can when developing to add security. I don't always catch every issue. I haven't yet done escaping on every db call, or filtered all user input in every app I write. But there is a difference between not having accomplished it, and not being aware of it.

I was trying to be helpful, and point out a real flaw that *I* find to be worthy of concern, after people asked why I switched.

Next time I won't bother. I'll simply say, fairly, that I have my reasons, and that people should keep that in mind.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Next time I won't bother. I'll simply say, fairly, that I have my reasons, and that people should keep that in mind.
I'll just note people argued against the content of the reported issue - not the fact a report was made. I wouldn't view this a discouragement to stop reporting what you see as an issue - would be a poor open source environment if that happens... The disagreement wasn't over the risk - but more who was responsible for it. You view the TE as reponsible, I view the developer as responsible. Maybe you don't see that distinction or don't agree with it. Either way - don't take it as a sign to cease and desist future reporting...:)
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Indeed. As an outsider and not a security expert at all, I did enjoy the discussion. In the sense that I learn from it.

Knowing what security is or means - obviously something people disagree on - is just as important as knowing how to escape some variable for some database. And a discussion like this teaches me a lot about this.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I think people clearly understand the point you have raised about secure mode. But then you say something that like the following that is very misleading to the point of be a misrepresentation of fact.
Roja wrote:I've brought up a risk (template engine executing code), and pointed to multiple situations that could turn that into a serious risk.
Installing any PHP scripts will create "multiple situations that could turn that into a serious risk". Templates are no different than any other script evaluated by the parser. Allowing anything received from an untrusted source to be evaluated by the PHP parser is a security risk -- that's the bottom line.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

So...this disscussion has switched from TL having a security flaw to having a security risk??? :P

Big difference IMHO... :)

In anycase...I think your arguing for the sake of arguing...although your arguments are technically accurate, they are not appropriate for the context of this disscussion...

Yes templates may be able to execute arbitrary PHP code...but how is that code going to get into the template? Untusted source you say...ok fine...but whats stopping that untrusted source from simply uploading a rogue PHP script and doing whatever they want anyways???

These questions have all been asked before and I think the answers are obvious...as well as the general consensus...

There is no flaw...there is only risk...where the difference lies is that, a flaw...by it's nature requires correcting a systems design and is outside the control of a client developer...whereas a risk requires optional circumvention by the client developer or admin - depending on it's use!!!

So in short...sure there is a risk...but by that logic...you might as well remove everything useful from your web server and have apache sending static web pages...

I think this disscussion should be locked as it's not really going anywhere and clearly everyone has their minds made up...at least I do :)

Cheers )
User avatar
AKA Panama Jack
Forum Regular
Posts: 878
Joined: Mon Nov 14, 2005 4:21 pm

Post by AKA Panama Jack »

Well, Roja is posting even more misconceptions and half truths about Template Lite in his blog.

I would have posted a comment on his blog about it but he is moderating any comments and deleting those he doesn't like. :(

This one paragraph is the biggest problem...
Roja wrote: Its not a theoretical issue. BNT and AATrade both pass unescaped user input to templates. Template-Lite does not filter that input, and unfiltered input can execute code. That means that templates could email player passwords to other sites, send notifications of attacks in game to others, or even perform database or file activities. In the example exploit code I wrote, I cause the template engine to print out the contents of /etc/passwd.
In that one paragraph he is giving the impression that Smarty will escape anything a user inputs on a web page while Template Lite will not.

Example:

Code: Select all

<input type="text" name="beacon_text" size="40" maxlength="50">
His statement implies that Smarty will escape code what the user types into the text box referenced by the variable "beacon_text" while Template Lite doesn't. The truth of the matter NEITHER template package will do this. Even with Smarty or Template Lite it is completely up to the programmer to escape, parse and check any input before processing it.

Now if he is talking about something else then he needs to get the terminology correct before posting something that will be interpreted in a wrong manner. It is unprofessional to post something like this without knowing the proper terminology.

If he is talking about the ability to execute PHP code within a template then that IS NOT passing unescaped user input to templates. With his current terminology he is implying anything you enter into a web page that is processed by Template Lite is at risk because you, the user, can enter something that will do something bad.

Now let's diverge slightly.

You can view templates like modules that can be installed that will offer displays with extra features and/or different styles.

The new version of BNT (Black Nova Traders) Roja is working on is going to contain modules that will allow admins to add more features to the game. What this means is an Admin can install user created modules that are written in PHP that could potentially send User information and Server password data to anyone. Any Admin will be required to examine line by line any module created for BNT before installing it if they want to prevent a HUGE SECURITY EXPLOIT from happening.

So then the question becomes, "Will Roja completely drop support for modules in BNT because of the security risk since the risk can be more detrimental than a template engine that has the ability to process PHP code?"

There is a risk anytime an Admin installs ANYTHING on their server.

There is a risk that BNT itself could copy the contents of /etc/passwd and send it to someone and the admin wouldn't know about it unless they scanned thousands of lines of code. In that respect BNT is a HUGE SECURITY RISK for anyone to install because they do not know if malicious code has been buried somewhere inside the programming. So to be safe no one should use BNT because of the Security Risk involved.

I really am getting tired of Roja trying to creatively manufacture non-existent problems with anything I write and release. It really is childish and petty. :?
Post Reply