As games get more intricate and many of you rely more and more on different plugins and tools, we want to make sure that you are able to do so in a safe manner. Content security is our #1 priority as we look to scale the Developer Marketplace so all of you can be confident that assets found there will only perform actions that you are aware of.
To that end, we are excited to announce our first iteration of plugin permissions: granular HTTP permissions. Now, whenever a plugin makes a web request to a new domain, you will see a pop-up dialog requesting you to approve or deny access to the plugin for that domain, or cancel the individual request. These permissions will be persisted across sessions and are configurable via the Plugin Management page at any time! HTTP permissions will be requested every time any plugin makes a new request from any domain that it has not previously made a request to.
Accepting or rejecting the domain from the dialog will remember your preference for the given plugin and domain.
Closing the dialog without making a decision will reject the current request without remembering your preference.
All previously existing Studio plugins will now use the new model and ignore the gameās Allow HTTP Requests setting - that setting now applies only in game, and if you are not making HttpService requests from your game, you can safely turn off that feature without losing plugin functionality from popular plugins.
Local plugins will bypass permissions.
This feature will ask for request on a per-domain basis. All sub-domains will need to be granted explicit permission.
This is just the tip of the iceberg for content security. Our team is working hard on the next set of permissions to help mitigate some of the major weaknesses reported by all of you including preventing unauthorized game teleports and script injections.
There was a huge loop-hole I had found about a year ago, that could have plugins get the userās IP address and post it to a server. I emailed Roblox about this several times, and they fixed it.
^^ The reason that worked is Roblox Studio is connected to the userās local IP address, which is not the biggest deal but it is a infiltration of user privacy ( not connecting studio to the userās IP, stealing an IP address is an infiltration of privacy and dangerous ), so that meant plugins can post a get HTTP request from a userās local IP address and then post a request to a server with the userās IP address, and boom, it was stolen.
I am legitimately so happy Roblox finally fixed this, now I feel a lot safer using plugins.
Hopefully this is opening the gate for other plugin permissions, such as preventing plugins from using require if we donāt explicitly allow it. Cough, backdoors. Remove require from the executing environment if we donāt allow it, wham, no oneās requiring modules if we donāt allow it.
Might be problematic for legitimate plugins using require but itās still good to be informed that the plugin is using require at all and what exactly theyāre requiring (either an outside asset or something within the plugin) so that we can decide whether or not the plugin should be allowed to continue.
Great to see this feature finally coming into play. This will increase users safety while using plugins, rather than their personal information getting exposed. Along with preventing plugins that have backdoors in them, which there is a ton of, overall Iām glad this feature is out now.
Iād instead make it fail for asset IDs, rather than removing require entirely - remember that requiring module instances is a thing. My plugins depend on that (for non-injection purposes)!
edit: for context:
Modules (and implicitly, the ability to use them) are critical to my coding best practices. If I lost the ability to manage my code using them, Iād be pretty tempted to just stop making plugins until a reasonable alternative came along. Maintenance would be a nightmare.
Added that to the bottom. Thing is though that itās a slippery slope so Iād prefer rejecting unauthorised requires altogether. Exploiters can adapt by simply integrating the module within the plugin itself instead of making it an outside require. Easier for us to vet infected code but they can bypass the id restriction.
When you say ālocal plugins will bypass permissionsā, does that mean that plugins put into %localappdata%/Roblox/Plugins will just be able to send HTTP requests without any restrictions even with HttpEnabled set to false?
If so, I like where this is going. Plugins installed on the file system should always have had enhanced permissions, and if that trend continues Iāll be happy.
I donāt really see how it would be a slippery slope - as long as the restrictions are transitive (i.e. modules required in a given context are subject to the same limitations as the calling context), then thereās no risk at all. Itās like running code from a function, except the source code is in a different local container.
Anyway, this is a bit off topic, so we should move somewhere else. New thread time?
This is awsome,but i just thought of a thing,what if that HTTP Request, is constantly requesting,resulting in the player not being able to edit the game?Or there will be something to stop that/that wont happen?
This can be done in-studio, but cannot be done in-game. If youāre doing this in-game, you are basically stealing the gameās IP address ( server where everyone is connected to ). If you do this in team create, it will simply just post the server IP that everyone is connected to. if you do this on your own , youāre stealing your own IP. So yes, this privacy concern has been patched by Roblox. Previously, anyone could make a plugin and steal a different userās IP address. That was a way bigger concern than now.
This is great and Iāve wanted this for ages, thanks for adding this!
Canāt wait to see more granular plugin permissions. Another big few ones for me are preventing plugins from reading/writing to datastores, modifying Source property of scripts and modules, and inserting other persistent objects/properties into the DataModel, although for that last one Iām not entirely sure what would be the most elegant way to prevent that.
Of course, it is studio only problem, but what I was saying you can make the plugin create another script hidden somewhere to do the HTTP Get to still receive the users IP once he playtests the game in studio. This change has only limited getting the userās IP address upon opening the studio.
This is definitely a step in the right direction but a lot of these malicious plugins install scripts into the game that only make those HTTP requests in a live game server outside of roblox studioās control. Iāve also seen some that use TeleportService and teleportData and make the requests in a game outside of the userās control. Maybe some sort of plugin permissions thing such as what mobile apps have currently is due? For example, āthis plugin needs X permission to do X thingā.
In regards to spamming requests to the same domain, denying the first request will automatically deny all the rest as well. I donāt know about spamming requests to unique domains, though.
