One of the biggest weaknesses of hosting your own server with HTTPService is that if someone gets a copy of your place somehow, they find out how to access your web server, and have free reign over it if/until you find out that it’s been leaked and change the security key. Is there any way to secure webservers so that even if someone gets a copy of your place, they can’t use your webserver?
Things I’ve considered:
Obfuscating the code well so it’s difficult to understand and work with
With enough time, can be rendered ineffective anyway
Making the web server do sanity checks on requests
Prevents majorly bad things from happening, but not seemingly-normal things like “yes, I totally finished this level I was on”
Implement API keys on your web server and store the current API key in a model that can be accessed by your game, then if they get the place they won’t get the API key. Also, for extra security, you can simply refresh the API key every week/month because you can just update the model to do that.
Also I think requests sent by HttpService have some headers predefined, you can check if those are present and otherwise flag the request as being shady.
In addition to what @buildthomas is suggesting you could store part of the access key in a data store and part of the access key in a place file (that way you’ll need both access to the place file and ability to run server code as part of your universe to get it).
I was under the impression that you can require a private module from an arbitrary game - which means that if you have the source of a place file it’s trivial for you to actually get the key from the module by asking it to give it to you, or by asking it to perform web requests on your behalf.
I can’t remember how they work entirely but I believe you’re correct now you’ve mentioned it. InsertService might offer the solution to that though since you can’t insert other users models.
Yeah I believe this is what @buildthomas is suggesting and it would work unless you get access to the model file as well.
It depends on the threat model. If hypothetically speaking somebody discovers a way to steal any asset on ROBLOX (it’s been a looooong time since that happened and it’s extremely unlikely this happens again but who knows), they could steal both the place and the model but can’t really get to data store. Maybe there’s a third way I’m not thinking about - the more independent exploits you need to come up with to steal your key the more secure it is.
Also for model files it’s enough to get a server code injection exploit in any place that the victim owns - so if you have any places that enable loadstring on RCC it may be possible to exploit them to load & dump the model file used by another place that you actually want to secure.
So to solve that you can introduce a hash function h(x) into your main game where x is whatever is in the model, and both the game (only that game, since the function h is not available in other games) and the web server know the value of h(x). Exploiting the model will only yield x in that case and the exploiter will have to find the right hash function then which is pretty infeasible.
If you can get both the place and the model you’re still out of luck, but it at least would improve the case you mention.
Maybe you can store the salt of the hash function in datastores, to add just a bit more of security (if the place and model are leaked both, they would still need datastore access to be able to invoke the hash function correctly)
You can just split the API key I believe, no need to hash. Probably the best you can do today is to split into three pieces - model, place, data store. You can get place if you steal it (via social engineering), you can get model if you get server access to it (via loadstring exploit in another place), you can get data store if you get server access to it (via loadstring exploit in a place in the universe or tricking the developer to use your code in their place or smth), but getting all three is non-trivial.
Also in theory we could introduce a first-class secure access key storage - Travis CI does this reasonably well where you can encrypt a secret and store it alongside your profile; they filter it out of the console output so that you don’t leak it even if the URL with it does get leaked,and we could do this as well (+ extra API for HttpService so that the only way to retrieve this key is to pass it directly to HTTP APIs in some form as a query parameter or header).
I think it should just be accepted that, if you give someone team create access to a place running a game in a production environment, all bets are off regarding secret / asset protection. In other words if you want to keep certain secrets or keep certain assets from leaking you should just team-create in a test environment where those things aren’t present
For example, at some point there might be some desire to have localscripts/scripts be treated similar to how the client handles them. Or perhaps the ability to mark some scripts or instances as private, even when in teamcreate
Isn’t it possible for SSL/TLS to authenticate both parties using certificates? Then a game creator’s server could verify that the connecting client is a ROBLOX game server.
No idea how hard that would be for either side to implement, however.