Introducing Plugin HTTP Permissions

Updates Announcements
#24

Good on you for pushing out a much-needed security feature. We’re one step closer to total sandboxing of plugins, I think.

Out of curiosity, is the team deciding mod policy and the team that do Studio updates separate? Cuz the studio update team is awesome.

#25

Oh, thank you, but, what if the plugin sends various HTTP Requests, as you said,for example, of scam websites, that would install into your game, scams, which could result in your acc banned.So, will this happen, and if it does, how would i prevent it?(This is an global question,because you said you didnt knew,so you dont know.)

#26

Much needed update for security, I’ve had trust issues with plugins ever since people started abusing the backdoor with private modules. Roblox obviously fixed this, which is a good approach to dealing with it.

This makes the security from installing plugins go even further. HttpEnabled usually isn’t enough anymore as many plugins require it to do stuff such as fetching the API or publishing content to external websites (in a good way :slight_smile: )

ps

How would a plugin be able to access roblox.com, doesn’t HttpService block requests to ROBLOX APIs.

1 Like
#27

It’s just an example screenshot.

3 Likes
#28

This doesn’t seem like a “major weakness” and honestly I don’t think I have seen anyone use HTTPService inside a Plugin for malicious intent. I’ve gone through hundreds of “backdoor plugins” (I am referencing plugins that inject a backdoor into your game, usually by requiring their own module) and none of them used it to steal my IP. And, what are they going to do with my IP? Tell me my timezone??

I do like that updates are being made, but I don’t entirely support this one. Thanks for the updates though!

2 Likes
#29

If I understand the question, HttpService.HttpEnabled is no longer used for Studio plugins with this change. Only in-game scripts using the HttpService will depend on the permission from the game settings dialog.

3 Likes
#30

Awesome! That answers most of the question, but just to clarify, will plugins read HttpEnabled as true, and will they respond to property change events on HttpEnabled?

#31

Yes! This is a great change. Perhaps you could introduce something like this for individual scripts too? I think that will patch a lot of those pesky backdoor scripts which are in free models sometimes.

1 Like
#32

This has been a thing for years, back when LocalScripts could do the same thing.

This update is covering a very niche and pointless case.

EDIT: @RBX_Lua came up with a more realistic and deadly scenario that I fully agree with.

2 Likes
#33

Can these request’s point to roblox domains (unlike httpService)?

#34

It would have previously been very easy for someone to make a plugin that checked for HttpService.enabled and exported your entire game over HTTP to a private server. You’d never know, because HttpService doesn’t log anything to the output, and they could easily avoid generating errors.

If having your entire game potentially exported and stolen without your knowing isn’t a security issue, I don’t know what is.

Why not? At the very least, it even makes enabling HTTP access for plugins that you plan on using easier. I personally fail to see any drawbacks that could accompany this change, unless it’s now significantly harder to implement HTTP as a plugin developer.

2 Likes
#35

Just noticed there was a typo in the management widget.

image

#36

I have never seen someone create a save place backdoor with plugins? I go through alot of backdoor plugins daily too and I never found one which would just collect all instances and properties and send it to their host.

2 Likes
#37

Another amazing update, this will fix many backdoor plugins.

#38

No, it won’t break any of them.

All of the ones I’ve seen only use HTTP Service for discord webhooks, it won’t prevent them from executing code in your game at all.

2 Likes
#39

I’ve seen a bunch of them, there used to be a drama pretty much every month because the owner of the project i was working on was not very smart and managed to get a backdoor plugin or an infection plugin, even when i told them to stop getting plugins.

#40

It feels redundant, but I guess you’re right that it does at the very least remove a potential security concern, and so that is good!. It protects any user who doesn’t protect them self first.

EXTRA

I am used to looking at the source for plugins before I install them. If I see something malicious, or something I don’t trust I simply just don’t install it. If I see something “obfuscated” I just wrap the environment and check if it ever grabs HttpServiceand what methods it calls.

3 Likes
#41

It might seem like a strong point at first but like @vw1ze said I haven’t encountered it yet either. Not to mention plugins are for productivity so what would they be stealing anyways? An incomplete game that hasn’t been tested for bugs? I think the stuff it covers is incredibly specific. I would say the aim of most of these plugins is to have some sort of power in the game rather than to steal it. However thanks for shining some light on that issue since I hadn’t thought of it when I wrote my previous post.

2 Likes
#42

This will not help because said backdoors usually just inject some new source into your preexisting source.

Example (hacky code but it is an example):

Iterating over the entire game and finding a script to inject their “require” into.

local descendants = game:GetDescendants()

local function inject(serverScript)
    serverScript.Source = serverScript.Source .. "require(123456789)"
end

for i, descendant in pairs() do
    local success1, isScript = pcall(game.IsA, descendant, "Script")

    if (success1 and isScript) then
        local success2 = pcall(inject, descendant)

        if (success2) then
            break
        end
    end
end
2 Likes
#43

I suppose that’s a good thing, then? Just because you haven’t personally seen it, or even because it hasn’t been done before, doesn’t mean that it couldn’t have been. A security vulnerability is a problem that needs to be resolved, even if it hasn’t been exploited yet.

To say “I haven’t seen someone do this” as an argument against fixing a security vulnerability doesn’t really make much sense. Imagine building a website with an obvious SQL injection vulnerability and neglecting to fix it because nobody has exploited that weakness yet.

I really don’t understand this argument at all. Are you saying that people don’t open fully completed place files in Studio? Or update existing, already popular and/or profitable, games?

Some games are worth thousands, if not millions, of dollars. Those assets are what they’d be stealing. Having an incredibly valuable asset potentially exported and stolen by a plugin right in Roblox Studio is a massive risk, in my opinion, and any effort by Roblox to mitigate that risk is certainly a positive change.

That’s a good practice, but not everybody is a programmer who would really be able to tell malicious code from normal code. In my view, efforts by Roblox to protect normal users from plugins is a move in the right direction.

5 Likes