You could easily setup some sort of strike system. After adding sanity checks to your remotes to secure them, simply store the number of times a player has sent bad information to the remote. If they get a certain number of strikes then kick them. There is probably 100 different ways to secure remotes but this would be a good place to start. Also never have the client tell the server to do something that the server already knows/can do itself. In other words why tell the server that the client purchased gold? Why not handle the entire purchase on the server? Have the client tell the server that it is “attempting” to purchase the gold. Little things like this make your game more secure.
Actually if you’ve checked it out, purchasing gold is done via in-game currency, meaning it isn’t a part of MarketPlaceService. You can’t use the security of MPS because it does in fact have to be with a remote event. However, you still have to do security checks to make sure it isn’t an exploiter.
1 Like
Ooof, then yes do security checks. I should of checked around more.
I know of an easy way to secure the shop remotes — if the values are off it never runs it
e.g if the client says buying 23 gold for -1000 gems, that is not one of the preset options so nothing happens
So as of now the troublesome remotes seem to be:
- Combat Remotes (he is spamming those to instakill people)
- PurchaseGold (abusable for getting both gold and gems)
1 Like
The client shouldnt even have to tell the server that, the server should already know the price of each item. The client should just tell the server what item its trying to buy.
1 Like
Actually, that’s a cleaner way to code it and think about it. Thanks
As far as I know, Roblox has limits on how often a client can fire remote events/functions. If a given client is spamming a remote, after a certain threshold is passed roblox will start timing out the client.
I do not have a direct source for this information, if I find one I will update this post.
EDIT : Found the source. Release Notes for 337 - #12 by ConvexHero
3 Likes
You can exhaust remotes but you can still easily crash/lag servers by spamming them if thats what hes talking about, especially if the remotes error or you just have some heavy code running each time. (Unless something new came out limiting remote spam more?)
1 Like
I recall an engineer stating in some thread that they’ve made remote throttling better, and that they couldn’t be spammed by exploits as easily. I don’t remember which thread it was, it was sometime in 2018.
1 Like
PurchaseGold should be unexploitable in new servers… thank you
1 Like
I can’t find an article for that, but the limit is 50 KB/sec occurding to the roblox dev site
1 Like
I heard a few people talk about this here and there, but I’m still super worried about this. If you could find that reference it would be great
As I said before, you should be having a debounce for each client on each remote. Despacito has said that he spams your remotes to get free money. I believe he mentioned that he could spam {0,0} to the purchase gold remote and it will glitch out the remote.
As for the combat one, combat should 100% ALWAYS have a serversided debounce. It should be handled 100% on the server. The client should literally only send when the player sends input.
Bottom line is, your hacker is very helpful in dispelling his methods. Remember to never trust the client and flag any sort of suspicious activity to your mod team. If you find exploiters in a server, you may want to ask about what sort of vulnerabilities they are exploiting (if they give it to you) and put in server side warning to see when remote events and functions are firing and from what client they are from.
Also people are talking about a limit on remote events - I’m not sure if it’s a real thing but the exploiter I asked said he had no trouble spamming remotes.
EDIT: So it is a real thing but the exploiter still was able to spam remotes. ¯\_(ツ)_/¯
3 Likes
4 Likes
as i mentioned in my reply, there is a limit in place internally. you can’t trigger the limit under normal conditions, the limit tl;dr will prevent bursts of event invocations at a rate faster than you can achieve normally, hence the denial of service attack.
events shouldn’t have a debounce unless necessary, it’s clunky. I outlined how to properly implement this in my reply too, however the issue you mentioned should be resolved with proper error handling instead of adding an arbitrary debounce (plus the $ shouldn’t be sent as an argument to the server anyway).
4 Likes
Make sure you “Type check” what gets sent from the clients aswell, if the server is expecting a string then make sure you check if its a string. Expecting a number? make sure its a number. @Osyris has a great module for stuff like this. "t" - A Runtime Type Checker for Roblox
2 Likes
In OP’s case, it is necessary as the exploiter was able to spam events enough to glitch them out. Now, of course the events could be glitching out for other reasons besides a lack of a debounce, but it was the first thing that came to mind as it happened to me once.
Proper error handling is a must and should be implemented always. I’m not sure if it will fix everything here, but it will definitely help OP
it isn’t necessary, in-fact I’d say it’s counter-productive. type check input and implement proper error handling instead of manually rate limiting the events, which takes time and can get pretty clunky.
compare something along the lines of if typeof(x) == y then ... else ... end to implementing limits on the logical functionality of events.
Not trying to bag your work or target you, but I’d recommend against doing that for those reasons 
.
4 Likes
I believe the current vulnerabilities Despacto used are fixed. I will get to type checking next, this was also something I was unaware about.
Thank you all so much, this has been extremely helpful.
This is not true and nothing but a baseless accusation. Please do not spread rumours.
Aside from the responses already given, well, your post is fairly vague. You haven’t explained specifically what exploits you’re encountering, only a list with “etc” attached to the end. That being said, the exploits you listed are just common cases of bad coding structure and lack of security.
Remotes are rate limited on the backend and if you drop requests that don’t pass checks, then exploiters firing remotes is a non-concern. They already do that with several games. Unless your remotes are accepting those requests and doing something expensive each call, doesn’t matter.
Look into securing your server. There are tons of resources in and around the DevForum regarding exploitation prevention and such.
FilteringEnabled is default in all games and cannot be toggled. Proper way to refer to a “FilteringEnabled game” is just a game. Games that didn’t have FE were experimental games. There’s no such division between “FilteringEnabled games” and “games” anymore.
And it’s typically these exploiters that most likely have dynamic IPs or VPNs as well for that very reason, ignoring the casual ones who don’t have any understanding of cleaning up their trails. Don’t rely on any kind of moderation; it’s fancy to have and it blocks out an account but it’s not scalable. Most exploit prevention should come down to automation done by your server.
Shooting yourself in the foot for no gain is a bad idea. This is a form of security through obscurity, which isn’t obscurity at all. Randomising remote names gives you no gain. Exploiters can read the traffic going to each remote and send their own input or track down the purpose of a remote.
False positives can be flagged. Major money gain in games does exist. In the first place, this won’t do much: an exploiter can work around this very easily. Increment small numbers or adapt to the watching that the server does for values. Simple answer is not to let the client be authoritative of any stat exchanges, it should only be sending requests.
1 Like