I don’t think loadstring is the right move here. Feels like a sledgehammer of a solution, and opens you up to all sorts of fun exploits.
I agree with @Hexcede – presumably you have some sort of tree data structure. Instead of converting that into actual lua, and then running that lua with loadstring, you can just evaluate the tree directly.
Surely though if I’m using loadstring in the server and the only code that can be run is predefined, that prevents most exploits, right? I’m not using the typical Loadstring() but using a “Lua in Lua VM” Module in server storage, so the client shouldn’t even be able to see it. Not that the client can run loadstring, anyway, but I suppose it’s still better that way as the player doesnt know the indexes for functions.
Especially as the code being run is set by the server and can only be chosen by specific indexes, anything that isn’t a valid index is ignored.
I suppose it’s all down to how I handle the visual compiler to prevent anything that shouldn’t be run. Also, values sent as parameters will be overridden by the server if they are unusual e.g. if you try to make a walk speed be 5000 it will be clamped to 50 or some max value.
If that is the case, why not just have visual blocks map directly to functions, rather than mapping them to strings, creating valid lua code from those strings, and passing the whole string to a VM? Cut out the middleman, in other words.
Yeah, I have decided now that’s what i will do. Each visual node will contain a function name and some base parameters that will be passed to the server, which will check for errors and then write function calls inside a string with the parameters inside. The script contains a reference to the function module and a container with the string. When run the script will simply call each function from the module based on the string passed to it one by one until none are left when the script will then delete itself or deactivate or something idk.
Blocks are a good idea, just make sure that any user input like defined variables are checked for stuff like escaped strings, etc.
-- for example this:
local function loadPrint(msg)
loadstring("print('"..msg.."')")()
end
-- would expect to be used like this:
loadPrint("Hello1")
-- but could also be exploited like this:
loadPrint("Hello2') warn('Code injection!') _=('")
Ah yes, I didn’t think about that! I suppose I can check for certain characters like ", ', [, ], (, ) etc and block those unless required, and then perform additional checks when those characters are allowed to make sure they aren’t being abused