WARNING ABOUT STORING SENSITIVE DATA IN PROJECTS

JaecadeJnight

TL;DR: don’t store private or secret things in CreatiCode like user data if you wanna make an app like a social media or something because databases and storage is able to be hacked regardless of you hiding your code blocks when publishing a project, which is not great. CC isn’t popular enough for that to even be a possibilty currently, but when its audience becomes more diverse and starts to have people inspecting its code and looking for vulnerabilities, things could get ugly for some projects.

Sorry for the all caps title, but this mainly concerns anybody doing anything with databases and chatting systems (like what @Tyller_ is making). You don’t need to take immediate action, but I’d say by at least when CreatiCode blows up in popularity. Basically, CreatiCode is possible to hack (in many ways) so you should never be storing stuff like banking details or whatever, especially if youre a famous/often targeted person. I say this because of the nature of Scratch itself, which it’s built on, its past vulnerabilities, and other things I can sense coming mile away. I know with my game YOUniverse3D that people are going to attempt hacking it and therefore hacking CreatiCode, so I want to let it be known in order to minimize the potential of destructive actions caused by random internet people. With my game that won’t be much of an issue because data is stored on my personal site and server, and hacking the game wouldn’t provide much benefits other than fun.

What I have observed

CreatiCode allows for data storage with things like databases and private/public variables which is “secure”. A SUPER big programming principle is “Never trust the client”. The client means the user’s device. For example (dw, creaticode doesnt do this), a horrible thing to do would be coding a login page on ur site that checks if the username and password are right by having the server send the password corresponding to that username and having the client check if the submitted password is correct, and then doing tasks as normal. On the outside, it might look normal to you and you’d likely notice nothing weird. But to get on the inside, anyone can juse use “inspect element”, edit the page code to show them the user’s password instead of using it for validation, then now the attackers can log into ANYONE’s account and takeover as they please. CreatiCode (as in the site and forum) doesnt do this, but this basically what’s possible with the playground/project runner if you’re using databases or storing data in other ways for sensitive data like chat messages or passwords. CreatiCode is capable of making full feature packed applications and games, but you have to be very careful about security to ensure that users of your app/game don’t get all their user data leaked or destroyed. To make it easier to understand here’s a block code demonstration:

Here, the inputs of the username and password boxes are taken, the client goes to the server and asks the database to give the password of a user where their username is equal to that of the username box value, and the server/database return it to the client, the client checks if it’s right, and either lets the client go (“accepted”) or denies (“incorrect password”) . This is exactly how websites SHOULD NEVER implement validation, but the only reason to do it on CreatiCode is because it’s the only way. And right now (with my code blocks exposed to the public), someone can go inside the code and click a block and authenticate themselves (just let themselves in, not even like uninvited guests, literally trespassers). The playground offers nice web & utility-related blocks, but the thing is they run on the client and there is NEVER going to be a solution to secure validation or preventing project databases being letting in just anybody unless CreatiCode adds new blocks, implements a new project running system or feature, or changes the way the blocks are. I will give a list of suggestions at the end for how they could fix this, but my opinion is that CreatiCode shouldn’t be used for cases where you really need to make sure someone is who they say you are unless you are working with something simpler or where it doesn’t matter if someone hacks something on your project

And you may be thinking, “but I can hide my code blocks to prevent others from just clicking on blocks i dont want them to?”, but that is wrong, as client side restrictions that can be bypassed by anyone tech savvy enough. Hiding the source code of CreatiCode projects is rendered useless if someone flips open their webtools inspector or something and starts removing code and making the project editor appear as normal and then click a block like to give coins or mess with database blocks. Hidden code blocks (when you publish your project) won’t stop a hacker, because in order for the project to be run, the CreatiCode site has to send the project file to you in order for it to play it. The client/site then does all the work, but a hacker can easily intercept that and download the project and use a program to visualize that file or just load the same file in CreatiCode again but owned by them (like making a copy of the project) regardless of any restriction on the client. Although that wouldnt let them mess with your project, them understanding the code and figuring out how to bypass restrictions on a seperate copy is just as harmful since they could then perform the same thing on your project.

How CreatiCode could fix it

None of these options are 100% doable or would be overkill and would waste CreatiCode’s time/money/resources but they are purely hypothetical:

Projects are proxied, meaning instead of running on the user’s device, they run on CreatiCode servers and are streamed to users. The client would consist of the streamed visual project running (like video streaming) and giving the project frame inputs like clicks, scrolls, right clicks, left/right drag clicks, and key presses would send them to the server. This way, the only thing that the user can possibly do is inputs, they get sent to the server, and backend code magic does its thing, and plays a project. This would make projects unhackable because users will only be able to change so much and it would just change it for them on their side. This would remove capabilities like selecting text/ copy&pasting unless you make an even more complex system to handle things like that to make it more accessible and natural. With this it would be ensured that code that runs pertaining the server could not be modified by an outside source and therefore be trusted. This could make projects run faster, or run slower depending on how it’s implemented and they would also need to keep in mind other things.
And a doable one I actually might make a new topic about instead

Tyller_

@jeffreyrb03-gmail I have considered this and ngl all you’ve said is right. I have thought about how since the blocks are just xml and stuff and still the client needs access. I have considered making stuff more secure and the issue is indeed that hypothetically, if somebody really REALLY REALLY wanted to they could find out. Personally I haven’t checked inspect element yet but it defo is possible. Though I have some ideas for a secure way, but they require you to have a 24/7 server to do stuff (I do have this with my laptop that I use as a server which I may try implementing into my chat rooms).

(btw if you’re reading this and want to know my method, it’d basically be I only give the service worker account that creaticode uses for interacting with sheets access, this would be so that the only way to check for new data in the sheet is using the read sheet block. Then I’d have my laptop constantly scan that sheet for changes and any changes would get a response in like 1-3 seconds and then wipe the response to finish, this would allow the client to send a message and see that it’s been uploaded, or request the message history for a world and the server sends, any messages sent while the person is in the server would use my current cloud block packet system. edit/ps: Ik this technically wouldn’t be secure cus somebody could hypothetically scan all the various sheets, I’d have a bunch of sheets to receive data in so you can’t read one sheet a bunch and have to read ~10 every second to intercept data Edit 2: I have found I can use apps scripts in the google sheet to do this, and it may be the only way I can actually since there seems to be nothing in the external api to run stuff exactly when a sheet updates)

JaecadeJnight

@tyller_ Yeah I also havent checked out inspect element, it’s also against their ToS to “reverse engineer” or basically try to understand and hack their code, but I can just tell from the way it works how its likely implemented on the inside. I like your idea of only allowing the CC service account to access the sheet (I use that too) but once again, the hiding the URL is only a client barrier, because the project JSON (actually .sb3 but is still JSON) file has to literally be sent to the client to run it and to do things like for projects with source code viewable to show the code blocks using the Scratch GUI thing and modifications. That .sb3 would contain GS links in the blocks and somebody could then get the URL of the google sheet of yours. While that person can’t directly access the Google Sheet because they dont have access, CreatiCode’s bot account does, and they can just use the GS blocks to takeover your google sheet and itd be pretty hard to revert the changes if they make it spam a 1000 times per second. I recommend that you get the Google Sheets API for your backend (you have to make a google cloud project, and then go to apis i think and enable that API for your service) so that you can do stuff there, and remove CreatiCode edit access to your Google Sheet, but set the service account to viewer. That way, all attackers can do is try to capture data that is updated like every 10 seconds and becomes useless after that. I recommend you encrypt your data by making like a text jumbler or something with a key that randomizes everyday so even if someone has an old data log they stole from your sheets, they wouldn’t be able to do anything with it because it’s just a bunch of gibberish. I made my own encryptor/hasher but it is not all that secure and instead serves the purpose of making text unreadable/undecipherable at a glance by using ROT13 and taking the length of the string as a number and inserting it at the beginning of the string.
https://play.creaticode.com/projects/675deee356af495135f2a9c1

You could make your app super secure by changing the way it does its job each time therefore making any old data obsolete and useless to hackers and people trying to infiltrate it for whatever reason

Tyller_

@jeffreyrb03-gmail good point, but if I use apps scripts then I can write javascript for whenever a cell is edited, then just parse that data as a packet and show a response for ~2 seconds (so the service bot can get it and I can have a wait block to allow the apps script to register the data) and then the client deletes the response to show it received it (I can even add logs to try and watch for abuse) this method with even just 10 sheets (if google sheets doesn’t lag from too many sheets I could use 30 or 50) would make it so it’s hard to try and mass scr\ape [I couldn’t post because it thought I had a bad word in my post and I had to use the find tool to find it’s flagging the middle of this word] it through the bot (especially because there’s a rate limit, I did a brute force test of the rate limit and it seems every about maybe 20 calls of a read/write sheet it locks you out for about 5 seconds, something around that) so it would be near impossible

JaecadeJnight

@tyller_ brute forcing it would then make it unavailable for everyone then right? And abuse logs would be good but my opinion is that you probably shouldn’t use CreatiCode for this, especially since you cant do things like ban IPs and people can make alt accounts easily so yeah… Brb, Im gonna be gone for like say a half hour

Tyller_

@jeffreyrb03-gmail I’d assume the rate limit would be per client, and when creaticode gets popular there would likely be some people using a forever loop read from a google sheet in regular projects, and to brute force you’d have to do that (since the delay on sending and stuff would most likely be on the server side) even if somebody dove into the scripts to reverse engineer it. PLus my reason for making it in creaticode is because its meant to be for everyone here to have a chatroom instead of having to use forums, and I don’t want to just make a standard chatroom app (plus then I would have to do stuff like make sign in logic or use google oauth, and it would be hosted behind my ngrok url). I very much plan on eventually sharing the project so other people can (attempt) to learn from it or use it, though I want to make some improvements before making a version where I remove any references to the sheets url

JaecadeJnight

@tyller_ That makes sense. If you know NodeJS and socket.io / websockets, would you want to help me making a DM/saved chatting system for YN3D? I have/use the perspective API (https://perspectiveapi.com) to filter out toxicity and harmful content, which I applied for to use in my google cloud project and I also saw there I can apply for other API access like gmail and google sheets. That can for the most part do content moderation pretty well and it’s free. That way forum users would have a secure and safe place to chat, and YN3D would get more users as a result

Tyller_

@jeffreyrb03-gmail sure, though I can mainly help with debugging as I know general node js, I mainly know how to make discord bots but have dabbled in the sheets api, you need to make a google project (I don’t remember the url) and to get a service worker to interact, though I’d assume if they have a sheets thing it would be in the extensions add on section

JaecadeJnight

@tyller_ i have an sqlite database i dont need google sheets dw

JaecadeJnight

@tyller_ can you request to join https://glitch.com/edit/#!/yn3d