Repository navigation
Security issue #467
Description
Activity
This only makes it slightly harder for someone who knows what they're doing, but it isn't unreasonable.
I personally always use a different account for cloud requests so i don't get logged out always and this would make it harder
I personally always use a different account for cloud requests so i don't get logged out always and this would make it harder
There could be a whitelists in a format like _twconfig_ inside of the project stage or in the instructions/notes & credits. But this is totally client side, so it's totally bypassable.
You should ask the Scratch team to do it because whatever we do is bypassable.
You should ask the Scratch team to do it because whatever we do is bypassable.
There is no way to prevent scratchattach from modifying cloud variables while still allowing people viewing the project to modify them. Even if the Scratch team updated the format used to send cloud variable updates, it would not be long before someone opens a PR to fix that.
There is no way to prevent scratchattach from modifying cloud variables while still allowing people viewing the project to modify them. Even if the Scratch team updated the format used to send cloud variable updates, it would not be long before someone opens a PR to fix that.
Maybe the Scratch Team would have some hacky way of doing it, and also there is no way for us to prevent it too so no one could do anything really, at least the Scratch team could modify the server side to make it harder.
The only thing that can be relatively easily done by the scratch team is to start banning people for hacking in the projects and making it so that banned users and new scratchers cannot use cloud variables
The only thing that can be relatively easily done by the scratch team is to start banning people for hacking in the projects and making it so that banned users and new scratchers cannot use cloud variables
I think they already ban hackers (I could easily be wrong in this one). New Scratchers already can't use cloud variables, this is an extremely well known fact.
A solution could be for the Scratch Team to make anti-cheat style protection by analyzing the Scratch project's code and determining impossible actions for normal-users and suspend access for a limited time. This solution would be hard to implement though. An easy solution is to let the project owners make their own rules and use that instead of analyzing the project code, this solution could even be implemented by a script using scratchattach to 0 some values based on an algorithm.
The only thing that can be relatively easily done by the scratch team is to start banning people for hacking in the projects and making it so that banned users and new scratchers cannot use cloud variables
I think they already ban hackers (I could easily be wrong in this one). New Scratchers already can't use cloud variables, this is an extremely well known fact.
the check as a new scratcher is client side. you can still send cloud requests if you make a web socket connection directly. same goes for banned users.
The only thing that can be relatively easily done by the scratch team is to start banning people for hacking in the projects and making it so that banned users and new scratchers cannot use cloud variables
I think they already ban hackers (I could easily be wrong in this one). New Scratchers already can't use cloud variables, this is an extremely well known fact.
the check as a new scratcher is client side. you can still send cloud requests if you make a web socket connection directly. same goes for banned users.
Turns out that they have very primitive protection that even just having simple checks for users might have an effect. For the time being maybe we could use external scripts that check for whether a Scratcher is a new one, or if they were banned (is that possible with scratch attach?) and zero the values they send combined with the other script idea I mentioned in #467 (comment).
Well, at least require an account for any changes, and Scratchattach can test for banned users without logging in.
wait, this is not already implemented, this would be so easy!
the point isnt whether it's easy. I think that limiting a client-side tool just makes scratchattach worse. Really this is a problem that needs to be solved by st. otherwise people will just use another library or an old version of scratchattach
currently cloud vars are down, and i think they are doing something about veryrealteacher
who is that?
who is that?
How didn't I think of using the api to see his info?
The only thing that can be relatively easily done by the scratch team is to start banning people for hacking in the projects and making it so that banned users and new scratchers cannot use cloud variables
I think they already ban hackers (I could easily be wrong in this one). New Scratchers already can't use cloud variables, this is an extremely well known fact.
the check as a new scratcher is client side. you can still send cloud requests if you make a web socket connection directly. same goes for banned users.
Wait, what? That is a massive problem
- Repository owner locked and limited conversation to collaborators
on Sep 29, 2025
Allowing people to change the cloud variables can be dangerous. There are some projects that use cloud variables to operate for multiplayer, some for high scores, etc. I recommend having it only change variables if you are the owner, because that's the purpose. Only the owner can change cloud variables to how they want without any additional tools, so we need this to do the same. So I'd like a future update to have that implemented.