PHP security: risks in evaluating a user-entered string

Question

Let me preface this by saying that I'm well aware that running user supplied code in a server environment is risky. Humour me - my question is specific to string evaluation and the subset of the language that can be executed in that context.

So I'm building a template generation system right now, and I want it to be fast. Super, super, super fast. This thing is going to get thrashed for mass email mailouts and that kind of thing. The approach I'm using is for users to supply user-entered template tags, which get turned into PHP variable substitutions via regexes before storing. Assuming my regexes are bulletproof, do you feel like the security of this process is acceptable?

• template is input by user, with tags like [[contact.name]] and similar.
• upon saving, regex transforms these into PHP variables, so the above wildcard becomes {$contact['name']} within the template string.
• We also check for the presence of anything that could be transformed into an accessible variable from superglobal scope, so [[_SERVER]], [[GLOBALS]] etc as well as [[this are all disallowed and logged as hack attempts.
• Other characters which have special meaning within a double quoted string ($, " and \) are escaped as well.
• the generation process goes like this:
  • generation is a class method that gets run. The only variable passed in is $contact, which is an array.
  • the template string is read out into another local variable (in this case, $__templateString). Users could theoretically access this variable in their templates, but it doesn't really matter if they do - not a security risk, just dumb.
  • The code to generate the template is then simply eval('return "' . $__templateString . '";');

Any holes I'm missing here? I am pretty sure the only potential risks are matters of scope access, and I think I've covered all my bases there.

Answer 1

Anecdotal drivel: When I was a security contact for a Linux distribution, the PHP developers asked us to stop calling interpreter crashes on malformed input "security vulnerabilities". They were adamant that whoever supplied the scripts was 100% trusted, and I would fully expect eval() to be handled the same way.

You can try to patch over problems but I certainly wouldn't open up input to unlimited users. The chances of you overlooking an interpreter-crash bug is simply too high.

Further, consider deploying with a mandatory access control system such as AppArmor, SELinux, TOMOYO, or SMACK. This way you can restrict the potential damage from a hacked input to the minimal amount of resources necessary to do the work in the first place. (I've worked on AppArmor since 2000, so it would be my preferred choice for many environments. But consider the others, they are all high-quality products designed to solve different problems and one or another might be a better fit for your environment.)

Answer 2

So what if I enter this template:

" . mysql_query('DROP TABLE users') . "

It's nice that you are guarding against possible access to variables you don't want people to access, but eval evaluates all code, not just variables. And try to find a regex to filter that out...