The command bar (which uses LocalUserSecurity) has more privileges than a plugin (which uses PluginSecurity), and plugins have access to the CoreGui.
You might be thinking of some API members that are restricted to RobloxScriptSecurity, but that constraint only applies to certain API members, nothing crucial that developers need presently.
I have totally stopped installing plugins unless it’s made by me or directly linked by someone trustworthy in the devforums. I don’t trust anything in the actual library right now, but luckily I haven’t needed anything (yet…)
You could also look at the plugins source. I remember there was a way to be able to view a plugins source. Where Roblox Studio is installed there should be some .rbxm files (which are the plugins) somewhere, then you can load/drag & drop them into studio and see their source. I will check if this still works when I get home (I’m on phone). Also, this could be a plugin security issue. Roblox might of parched this a while ago.
Why does OP sound targeted towards the common form of injection that malicious plugins are using as opposed to place vulnerabilities in general? I don’t think the issue is Backpacks, it should pertain to how to locate vulnerabilities in general. Malicious developers are just going to change the method of usage (e.g. Folders, Models, raw script objects, etc).
The change specified is ideal, albeit my opinions on the subject matter. Backpacks and PlayerGuis shouldn’t even be insertable or creatable - what use case would someone have to do so? Folders superseded using these objects as containers for storage.
I think the post is referring to the Backpack’s functionality outside of a player or the workspace. Normally scripts won’t run inside of any services so I’d assume the backpack bypasses this.
I think it would be an interesting idea where if a plugin wants to add a script to your game, it will give a popup (from roblox), stating where it wants to save to, allow you to view the code, and confirm/deny if you want it added. If you notice shady obfuscation or anything along those lines, you know immediatly to deny it. Just food for thought. I think it would help prevent many future instances that will try to add malicious code to hidden parts of your game.
I’ve got an Idea for how to prevent Users from seeing code like a modulescript, the dev can see the code it just hides it from the player by calling fuctions through remotefunction and remoteevent. Gotta develop it but I have school so after school I’ll create it!
To provide some more details about this vulnerability such as how it happens and what @Christbru01’s detection plugin is doing (it feels like the best way to combat this sort of injection is to be transparent):
Backpacks currently run scripts that are descendants of them. This is so that scripts can run while they’re parented to Players
This vulnerability is caused because Plugins can create Backpacks and Scripts and place them inside of Services that can’t be seen normally in the Roblox explorer.
Some services, such as the CSGDictionaryService, cannot be accessed by scripts, Plugins, or the Command Bar. Due to an oddity with how Roblox works, there are means to place things within these services but not get them out
Due to this, and how Backpacks allow scripts to run, a vulnerability is created by putting a script in these services.
Christbru01’s plugin uses some some more obscure methods to detect and remove these Instances. These include GetDescendant, pcall, and Insert.
Hopefully this better educates people on what’s going on here. I can absolutely vouch for Christbru01’s plugin. You can also do the trick Seranok suggested up at the top of the thread, as that’s a guaranteed method.
Specific to the injection done by the fake “Terrain Save and Load” plugin, scripts are also injected randomly in the Workspace, so make sure to check more than just scripts in Backpack objects.
