Security issue #503
Replies: 19 comments 4 replies
-
|
This only makes it slightly harder for someone who knows what they're doing, but it isn't unreasonable. |
Beta Was this translation helpful? Give feedback.
-
|
I personally always use a different account for cloud requests so i don't get logged out always and this would make it harder |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
You should ask the Scratch team to do it because whatever we do is bypassable. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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). |
Beta Was this translation helpful? Give feedback.
-
|
Well, at least require an account for any changes, and Scratchattach can test for banned users without logging in. |
Beta Was this translation helpful? Give feedback.
-
|
wait, this is not already implemented, this would be so easy! |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
who is that? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
How didn't I think of using the api to see his info? |
Beta Was this translation helpful? Give feedback.
-
Wait, what? That is a massive problem |
Beta Was this translation helpful? Give feedback.
-
Who even wrote this part of scratches code? Definitley not an mit student. They would've thought of that. |
Beta Was this translation helpful? Give feedback.
-
I imagine the cloud servers run on an entirely different codebase to the rest of the site. This might explain why it was easier for them to simply have a client-side check, and also it could explain how Scratch cloud goes down so often while everything else is fine. |
Beta Was this translation helpful? Give feedback.
-
|
oh alright |
Beta Was this translation helpful? Give feedback.
-
|
the auth at least is implemented differently as expired sessionsids can be used |
Beta Was this translation helpful? Give feedback.
-
|
Yeah... I'll just tell ST. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions