The runkit sandbox sounds useful as well though, maybe you could try using that in your safer eval() function?
The quest for safe eval() of user input
Moderator: General Moderators
Re:
Mordred, it seems it's you who missing the pointMordred wrote: You're missing the point. I think you should not need user-scripting for a game (or an app). Noone but a handful of geeks would be able to use it. And some of them will be better at security than you (and me).
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: The quest for safe eval() of user input
sounds like what you need is a language with closures, which PHP isn't.
Or maybe an API? Let their code run in a separate process and interface with your app. That's how FB does it, and it seems to work.
Or maybe an API? Let their code run in a separate process and interface with your app. That's how FB does it, and it seems to work.
Re: Re:
I don't think so. Even if this could be applied to PC games (which isn't exactly true, but I won't go into this now; the burden of proof lies on you anyway), I don't see it applied to web games. There are popular games with lots of users and modding, but they are open-source and modding is done directly on the code base, or by writing plugins. There are also popular proprietary games, but no modding is done on them (at least none that I know of, which actually isn't much, so please provide a counter-example if you know of some such game)Weirdan wrote:Mordred, it seems it's you who missing the pointMordred wrote: You're missing the point. I think you should not need user-scripting for a game (or an app). Noone but a handful of geeks would be able to use it. And some of them will be better at security than you (and me).: most modern games need built-in scripting. The scripting usually is not intended to be used by gamers - instead it's used by modders to roll a variations of original game.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
Re: The quest for safe eval() of user input
I can verify that many (real) games use scripting languages to define a lot of behaviors rather than actual code. Unreal engine projects will usually use UnrealScript, which is based on ECMAScript, for example.
Either way, the idea of using eval() is hideous. It's far better to create a sandbox. Whether it's has to be PHP or simply interfaces with one's PHP is a choice one has to make, but I would suggest the latter approach by building an API and then code for a language or three to communicate with that API so that third-party developers aren't forced to use PHP.
Either way, the idea of using eval() is hideous. It's far better to create a sandbox. Whether it's has to be PHP or simply interfaces with one's PHP is a choice one has to make, but I would suggest the latter approach by building an API and then code for a language or three to communicate with that API so that third-party developers aren't forced to use PHP.
Re: The quest for safe eval() of user input
Been there, done that, wrote the manual (literally).feyd wrote:I can verify that many (real) games use scripting languages to define a lot of behaviors rather than actual code. Unreal engine projects will usually use UnrealScript, which is based on ECMAScript, for example.
Yes, scripting is a great way to separate engine code from game code and allow for quick modifications without recompile (or even, if one is wise enough, without restarting the executable). The key point is that this is done for the benefit of the developers, not for the sake of modders (bar a few games that did this on purpose, to invite modders). Or, it comes free with the 3rd party engine you're using.
But gamers would not care for it. They don't need a fancy script language, they need to enjoy the game.
Modders would not care for it either, not unless the game becomes hugely popular.
Modders would also suck at modding, because they generally don't have the resources, talent or experience to make an enjoyable mod.
In the end of the day you are left with only a handful of successfull mods ever made.
(Rant off, I know that was not exactly Weirdan's point) So yes, modern games use scripting. What does this have to do with web-based games? (Okay, we may say the same of web-based games, PHP *is* a scripting language after all
I don't think it pays to go through all the hassle to support modding for a web-based game.
I don't think gamers would appreciate it if the game allows user-level scripting either.
And I definitely don't think eval() is the way to do that, but we've already established that
-----
@Kieran Huggins: closures? How would you use closures to provide a safe sandbox? You rather need a mechanism to limit the language's native API to a rich-yet-secure subset. This is trivial in some languages, and quite bordersome in others.
Re: Re:
On the second thought I would partially agree with you in that the scripting is used prevalently in PC games (I think it's dictated by the fact that most PC games are implemented in statically typed compiled languages like C, C++ and the like - an alternative would be a plugin architecture, but that would require writing a shared libraries - too much burden for a simple modder).Mordred wrote: I don't think so. Even if this could be applied to PC games (which isn't exactly true, but I won't go into this now; the burden of proof lies on you anyway), I don't see it applied to web games.
What an awful approach, don't you think?Mordred wrote: There are popular games with lots of users and modding, but they are open-source and modding is done directly on the code base
That is much better, but sometimes it's desirable to additionally limit what plugins can do (on the language / stdlib level).That's the point of having sandboxes - and personally I don't see how a PHP sandbox (via runkit) is radically different from eval sandbox like Hory is trying to build.Mordred wrote: , or by writing plugins.
Re: The quest for safe eval() of user input
First of all, sorry for not replying sooner, but it's only now that I've noticed this thread has a second page.
Regarding runkit - it's not a default PHP extension, right? That would it pretty much unusable on 99% of shared hosts.
As for why I need scripting in games - it's true that there are very few games in which the players need to do scripting themselves (e.g. combat "robot" programming games). In my case, I'm making a sort of RPG engine on which other developers could pre-script their stories and campaigns for players to play. So the third-party developers will definately need a way to script what goes on behind the curtains in their modules.
Building an API - yes, it might be a solution. It's just seems wrong to me, in a way, to put so much effort into it, only to have it do what PHP already does. That's why I'm trying it the other way around. I didn't want to make developers learn another "used only in one place" language either.
The only other thing I've found which seems adaptable without much effort is DORSL. But, as with most projects, development isn't active anymore, who knows what bugs or weaknesses it has, and even the documentation is so scarce that I haven't figured out how to use it yet. But I'm working on it
.
Regarding runkit - it's not a default PHP extension, right? That would it pretty much unusable on 99% of shared hosts.
As for why I need scripting in games - it's true that there are very few games in which the players need to do scripting themselves (e.g. combat "robot" programming games). In my case, I'm making a sort of RPG engine on which other developers could pre-script their stories and campaigns for players to play. So the third-party developers will definately need a way to script what goes on behind the curtains in their modules.
Building an API - yes, it might be a solution. It's just seems wrong to me, in a way, to put so much effort into it, only to have it do what PHP already does. That's why I'm trying it the other way around. I didn't want to make developers learn another "used only in one place" language either.
The only other thing I've found which seems adaptable without much effort is DORSL. But, as with most projects, development isn't active anymore, who knows what bugs or weaknesses it has, and even the documentation is so scarce that I haven't figured out how to use it yet. But I'm working on it
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: The quest for safe eval() of user input
Could you not run all user script inside a closure, passing in certain objects and limiting it's access to those? Maybe it depends on the language.
I'm probably full of <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span>, but it seemed like a good idea at the time
I'm probably full of <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span>, but it seemed like a good idea at the time
Re: The quest for safe eval() of user input
@Hory: You'll need to build a PHP API anyway - a set of allowed functions that the developers may call. There are many solutions to this without letting modders to write actual PHP code. Starcraft's level editor was entirely event based if I recall correctly, you might check how they did it. In fact, checking how other people solved the problem you're facing now is probably the first logical choice 
Anyway, you still need to address some more holes in your scripts.
@Kieran: A closure generally allows access to variables of a "parent" scope. It would not restrict access to variables of other scopes - for example the global one. From that point of view it is no different than just calling a function with a number of parameters. What Hory is trying to achieve, is to limit access to the rest of the variables (and also to some language constructs which is a double burden for him)
Anyway, you still need to address some more holes in your scripts.
@Kieran: A closure generally allows access to variables of a "parent" scope. It would not restrict access to variables of other scopes - for example the global one. From that point of view it is no different than just calling a function with a number of parameters. What Hory is trying to achieve, is to limit access to the rest of the variables (and also to some language constructs which is a double burden for him)
Re: The quest for safe eval() of user input
Someone could create code that runs infinitely making your website vulnerable to a dos attack.
For example:
For example:
Code: Select all
while(1 == 1) {$i = 5/0;}Re: The quest for safe eval() of user input
\o/ Bravo! \o/dayyanb wrote:Someone could create code that runs infinitely making your website vulnerable to a dos attack.
For example:Code: Select all
while(1 == 1) {$i = 5/0;}
Somehow finding code execution flaws made me totally forget about DOS-ing, I'm ashamed. Well spotted, dayyanb. You've just turned Hory's safe eval quest into a quest of solving the halting problem, which is proven unsolvable -->
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: The quest for safe eval() of user input
Indeed you are correct - closures isolate their own variable scope, but don't limit access to globals. But they don't allow access to the parent scope, do they? My understanding is that you have to pass in anything that you want to access. At least this is what seems to be the case in ECMA Script & Ruby...Mordred wrote:A closure generally allows access to variables of a "parent" scope. It would not restrict access to variables of other scopes - for example the global one. From that point of view it is no different than just calling a function with a number of parameters. What Hory is trying to achieve, is to limit access to the rest of the variables (and also to some language constructs which is a double burden for him)
Regardless, your point about malicious code is spot on. Closures are certainly not a solution here.
Re: The quest for safe eval() of user input
I was aware about the infinitely looping code, but really, isn't this a problem that any interpreter is susceptible to? Even the most limited of scripting languages can be sent into such a loop. Limiting script execution time might be an option, but, of course, it would still suck resources for some seconds...
Re: The quest for safe eval() of user input
On the contrary, this is exactly what closures are - a function, that accesses the local variables of the parent scope as if they were globals. If you pass them what they need to access, then it's just regular functionsKieran Huggins wrote:But they don't allow access to the parent scope, do they?
Hory, you still haven't fixed the damned code. And your web site code is vulnerable to multiple XSS and mail header injection.