search

SheepTester / primitive-cloud-server

A primitive Node server for Scratch 3.0 cloud variables; it's not made for large-scale projects and can easily be tricked by those pesky JavaScript programmers
MIT License
32 stars 34 forks source link

This is way too easy to "hack" into #14

Closed TheShovel closed 2 years ago

TheShovel commented 2 years ago

I am making a bigger scale multiplayer game and one of my testers found out that it is incredibly easy to modify cloud variables from another scratch project, that has the same cloud variables and the same project ID. That means people can just look into the index.html of my project, get where the server connects, and just copy paste the variable names, and just like that, they have full access to modify anything. The game I am making has an account system and all that (basically roblox but 2D, that meaning that people can save games to the server) and it wold be very sad if someone just deleted all the data. If you have a fix for this, or if you could make a more advanced mode that detects the clients in a more secure way, please tell me so I know if I need to code my own server from scratch or if I can still use this one in a more secure way. Thanks for your time!

SheepTester commented 2 years ago

The same applies to vanilla Scratch too, so this is working as intended.

A primitive Node server for Scratch 3.0 cloud variables; it's not made for large-scale projects and can easily be tricked by those pesky JavaScript programmers.

In order to prevent this, you'd have to write your own code on the server side to validate whatever the clients send in. This depends wildly on the project. To offer enough customizability to allow you to configure the cloud server to know what is and isn't a legitimate cloud variable value would essentially just be the same as having you write the validator as code.

Outside of Scratch, account systems usually work by having the client send data to the server, and on the server, it has code to check to make sure the values aren't bogus (e.g. the username is unique and not too long or too short and is free of weird characters) and then storing the data somewhere. The client does not do any of that work because it cannot be trusted. Even still, this process can easily be spammed; I think people usually overcome this by requiring email/phone validation (which can still be spammed, but at least deters some spammers), using a CAPTCHA, or relying on OAuth + a different service to sign in. That's outside the scope of the primitive cloud server, though.

TheShovel commented 2 years ago

The same applies to vanilla Scratch too, so this is working as intended.

A primitive Node server for Scratch 3.0 cloud variables; it's not made for large-scale projects and can easily be tricked by those pesky JavaScript programmers.

In order to prevent this, you'd have to write your own code on the server side to validate whatever the clients send in. This depends wildly on the project. To offer enough customizability to allow you to configure the cloud server to know what is and isn't a legitimate cloud variable value would essentially just be the same as having you write the validator as code.

Outside of Scratch, account systems usually work by having the client send data to the server, and on the server, it has code to check to make sure the values aren't bogus (e.g. the username is unique and not too long or too short and is free of weird characters) and then storing the data somewhere. The client does not do any of that work because it cannot be trusted. Even still, this process can easily be spammed; I think people usually overcome this by requiring email/phone validation (which can still be spammed, but at least deters some spammers), using a CAPTCHA, or relying on OAuth + a different service to sign in. That's outside the scope of the primitive cloud server, though.

Thanks for replying. I will try to make a fork of the server that has those systems in it than.