Security with PHP Only templates

There has been a bit of talk lately on the Savant mailing list. Then the same thing up on the PhpLondon mailing list so I figured i’d stop talking about the solution and start implementing it.

The big claim is that a compiled template engine like Smarty is safter because you can’t use all of the PHP functions but I think this is just a straw man argument. Since php 4.3 we’ve had a working tokeniezer extension and with that you can sit down in an afternoon and write some code to tell you what functions etc your using in your template code.

Then from there its just a matter of using Savants compiler to check the status of your script, or if you want it more generic just make a php stream.

Anyhow the first part of the effort is done you can download PHPCodeAnalyzer, or just read the docs to see what it does. Or if your really in a hurry view the live demo.

Posted in PHP

16 thoughts on “Security with PHP Only templates”

  1. Yeah Smarty people are kidding themselves I fear. I dont know Smarty internally, but unless they actually made this security option very cleanly implemented they will most likely have a really hard time to protect themselves from people who are out there to exploit their programming mistakes. Implementing security like that is hard enough as it is already, so unless you really take a clean approach at things you are bound to get screwed by someone thinking hard how to crack you. Again I dont know Smarty well enough to really tell, but potentially people could use smarty code to generate malicious php code.

    Anyways I am hoping that soon I will be able to donate a security policy analyzer. Essentially you tell the analyzer your security policy (may access these funtions, these global vars etc) so that you can check if the template matches your security policy for the user who is trying to integrate a given template into your system.

  2. Isotopp, you still want to be able to use all kinds of php in the rest of your code, just a limited set in your templates.

  3. essentially php lacks sandboxing .. ruby has taint, which I never worked with but sounds nice featurewise .. the API didnt look all too great.

    heh .. well you could use php cgi to render your templates with a strict php.ini … with aggressive caching things might even perform ok

  4. Lukas, right but what your talking about here is limiting the rights of code running inside a method in a class. I really don’t see how you could do that with a cgi especially since you’ll want to access the variables and such that are registered. I’m not sure how ruby’s taint work but most things i’ve seen don’t have the granulatity you need too limit just the template files.

    Unless you do something security policy based, which is what im halfway to writing with this code, or you go something much simpler then Smarty where you have a limited set of functionality that you convert to php code.

  5. What about dynamic functions, like $foo = ‘system’; $foo(‘/usr/bin…’);

  6. I’ll have to look but you can tell its a function call called $foo even if you don’t know what $foo is, so if your using a whitelisting setup it wouldn’t be allowed.

    I don’t really think you could make a secure policy without whitelisting, at least not without a lot of work to find everyway to get around it like that.

  7. well the idea would be to pass all the parameters you want your template to have via a call to your cgi php (actually you could have different cgi and/or php.ini’s). isnt that what you are supposed to anyways?

    the beauty is however that you retain the power of php within the templates … theoretically you could even allow people to run a query inside the templates if they really have to (sometimes you need quick and dirty and its nice to have as a possibility)

  8. A setup like that sounds quite klunky and slow, also i think it would be easy to write a policy that allowed that with a system based on code analysis, you just say let them call the methods of your sql api in the policy or something like that. Though i don’t really think the people who are looking for a solution like this want to let someone do quick and dirty things, but thats the whole point of a setup like this, you can optionally run it with say Savant or not.

  9. Well I just dont believe that code analysis tools will be as reliable as the solution I proposed. However yes its way too clunky and that is why I will probably also go the code analysis route for now.

  10. Well i think part of the problem with trying to limit things based on php.ini Is i don’t think there is an easy way to stop people from writing new functions or classes (unless i just haven’t seen that option in the ini).

    Any how if your goes the code analysis I would be willing to colloborate, well at least helping on policy engine design and further development of the code analysis class.

  11. I dont see a problem there really. All you want to do is prevent people from accessing internal variables and certain extensions. I dont think it makes sense to dictate what language constructs people should be allowed to use inside their templates.

  12. To me it makes a lot of sense. In many situations your not so much worried about security but that your templates don’t turn into a total unmanageable hack just because they can.

    But that could just be my view of the situation.

    Actually i can think of a situation were you could use a tool like this to certify that code was only using a standard api and thus could be garenteed compatible between multiple implementations of the same basic api, al la J2EE aplication verfication junk.

  13. Well now you are taking things into a different direction than security .. but depending on what you do it may be feasible to combine the two. Since all my html designers are within slapping range I dont have this problem quite as much though 🙂

  14. I really don’t have any production use for this at all, but I find the whole topic quite interesting. But yea i think i’d used it more along the lines enforcing rules in phpDocumentor templates then just for security.

    I should look at the phpDocumentor 2.0 code and build the analysis off of php_parser, but thats actual work instead of a proof of concept.

Comments are closed.