Isolation in PHP?

Question

Here's something I've thought about for a while.
I am creating an application where's my users will upload their own custom themes, which means that there's going to be a good opportunity for anyone with basic PHP/XSS/whatever skills to cause a lot of headache.

I would like to run any uploaded files in a sort-of sandboxed, closed environment that only has access to the stuff (variables) that I want and nothing else.

Would this be good practice and how would it be done?

Bushtit

you're allowing users to upload their own PHP and JS code? – Heloise

@Rook You shall have an upvote then.. – Judejudea

Answer 1

To allow arbitrary html/javascript safely then each user must have its own subdomain. If each user has their own subdomain then a user's JavaScript will be restricted their own sandbox because of the Same Origin Policy. If you only want to allow "safe html" then htmlpurifer is an option, and then you can use 1 domain.

Allowing custom PHP is a bit more hazardous. "Shared hosting" providers rely upon suPHP which forces the php script to run as a specific user. This would require every user to have their own account on your system. This method of defense has been around for a while. It isn't perfect but it does the trick.

Another possible solution for custom themes is to use a templating engine, which can prevent templates from getting full access to PHP. SOme popular frameworks for this:

1. smarty, it doesn't have the best secuirty track record, but you keep it up to date you probably won't have a problem. It needs to be configured to disallow native php.
2. twig is a relatively new engine from the makers of Symfony Framework. This means it has a decent developer base and since it ships with Symfony, it's also been tested in the wild. Twig does not allow any PHP functions to be called, unless you specifically create a twig function/filter for them.

Lait

i am really not sure whether i would trust smarty on this. also cant find any good documentation on how it works or what it exactly does. just that it "secures" php... can you provide resources? – Molloy

@Joe Hopfgartner You don't write in php, you write in smarty's own templating language, which relies on familiar php functions. – Lait

i know the smarty template language. its very similar and profides a limited yet use/powerful number of functions and control flows. however i thought this was about using native php code which is referred to in your link by Securing Smarty By default Smarty allows PHP code to be run within templates using {php}{/php} tags. it also looks to me as if the smarty::security option applies to this and not smartys own language. thats why i was confused. the documation is probably pretty misleading. – Molloy

@Joe Hopfgartner I don't know of a good article off hand. But i have dug into the smarty code. A smarty template is read in and then compiled into a .php file which is ultimately executed. Having a malicious user write .tpl files was apart of their attack model and there is nothing inherently insecure about this compilation process. – Lait

the process sounds reasonable to me. – Molloy

Answer 2

As you don't want to grant your users access to PHP, you should use a template engine that supports sandboxing. Twig is a prominent example here.

Brehm

I've added twig to the original accepted answer for a better overview in case more people stumble upon this question. – Knapsack

Answer 3

global scope will always be accessible.

but object oriented concept provide a lot. what you can't do is to hide global stuff. what you can do is not make it visible in the first place.

but executing unreviewed 3rd party code is a tricky thing. i would recommend some sort of process isolation here if possible. which means you open a process using popen or something, in combination with suphp you can make a restricted linux user. that is very well possible and secure with the correct security measures in place.

a good approach to run the code within the same program is to use the templating pattern. its a bit unpractical for classes because whole files get loaded that can inject hazardous code. but you can create custom functions in php from code. the code does not get executed unless the function is called. you can also extend a class to a variable name, which is then user supplied code. however this is almost unpossible to make safe.

when it comes to html code , it is way easier. there are good html tidy is a good start. there are good solutions to allow only speical tags.

javascript can be "secured" in a way that old facebook fbml applications did. which includes server side rewrites, dynamic variable names etc its quite complicated.

in my opinion the best way to allow external customizations is to allow external stylesheets. just load them from an external origin and there is not really a security concern.

edit: of course you can parse any code and limit it to certain statements or deny certain statements, but this is very tricky and for php a very heavy constraint. its probably better to switch to some higher level algorithmic languages or go client side with javascript.

Molloy

Then don't store anything in the global scope. Run your scripts inside a closure, and run the template inside another closure. By the way, the risk is high nevertheless, as variable stealing is not the highest risk factor. Escaping and validation is the key and should be done with the maximum care. – Grig

thats what i was referring to by object oriented concepts. but you can isolate as much as you like in your program if echo file_get_contents('config-with-database-credentials') gets executed... – Molloy

Answer 4

What you want to do is really risky. You should never allow your users to upload PHP files. That's why you don't find many PHP fiddlers around the net (though now there's some).

Also JS is dangerous in some indirect ways and pretty much nobody allows you to upload it (with the notable exception of Tumblr).

What you should do is adopt some kind of templating engine, and sanitize the templates the users upload, to remove scripts.

Since security is an issue, try to check security advisories like Secunia when choosing the templating engine.

Grig