WARNING ABOUT STORING SENSITIVE DATA IN PROJECTS
-
@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
@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
#LLJW
<span style="color:white;background-image:linear-gradient(to right, lightblue, navy)">My name is Jeff</span> -
@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
@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
<div component="post/signature" data-uid="255" class="post-signature">Check out my chat room project so you ppl can not use forums as chat rooms! https://play.creaticode.com/projects/66f2e1dcd1be43d82b886fbd?version=1 <p dir="auto">
</div> -
@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
@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
#LLJW
<span style="color:white;background-image:linear-gradient(to right, lightblue, navy)">My name is Jeff</span> -
@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
@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
<div component="post/signature" data-uid="255" class="post-signature">Check out my chat room project so you ppl can not use forums as chat rooms! https://play.creaticode.com/projects/66f2e1dcd1be43d82b886fbd?version=1 <p dir="auto">
</div> -
@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
@tyller_ i have an sqlite database i dont need google sheets dw
-
@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
@tyller_ can you request to join [removed by catty - safety]
-
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 projectAnd 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
@jeffreyrb03-gmail Why not put the authentication log in code inside the my block? What i mean is like this. The person goes to the log in screen, which triggers the my block, and asks them to put in their username and password, then it let’s them in.
-
@jeffreyrb03-gmail Why not put the authentication log in code inside the my block? What i mean is like this. The person goes to the log in screen, which triggers the my block, and asks them to put in their username and password, then it let’s them in.
@jamesa-blackwell-57b383d3 I literally explained in this post why this is a bad idea, please re-read what i wrote. But I will say it a different way: basically, if you’re making a database that stores things that should be secure and never read by the public (like secrets or passwords), then that is a bad idea, because anyone can easily hack it, including me. This is because the methods are literally just to request data, edit data, and remove data. So if I cleverly edit someone’s project (which is done by editing the project without remixing it, but it only shows for you), I can extract whatever what supposed to be private in an easy way with the browser inspector. Even if they made their blocks hidden, it would be very easy to mess up projects that rely on databases to function or to be secure. For example, if you made like a game that stores things in a database instead of something like cloud variables, which are user specific, then the blocks can be used against the project. In fact, I believe any project, even ones that don’t use databases are vulnerable to a hacking like this. Nobody is hacking CreatiCode right now, but I bet if someone smarter than me decided they wanted to, they wouldn’t have a very hard time because of the security vulnerabilities and over-trusting the client. In computers they said “never trust the client”, which is why you shouldnt just hide private things from the client, but also make sure that the private things are inaccessible if someone decides to edit or abuse their client (done with “Inspect Element” for websites).
-
@jamesa-blackwell-57b383d3 I literally explained in this post why this is a bad idea, please re-read what i wrote. But I will say it a different way: basically, if you’re making a database that stores things that should be secure and never read by the public (like secrets or passwords), then that is a bad idea, because anyone can easily hack it, including me. This is because the methods are literally just to request data, edit data, and remove data. So if I cleverly edit someone’s project (which is done by editing the project without remixing it, but it only shows for you), I can extract whatever what supposed to be private in an easy way with the browser inspector. Even if they made their blocks hidden, it would be very easy to mess up projects that rely on databases to function or to be secure. For example, if you made like a game that stores things in a database instead of something like cloud variables, which are user specific, then the blocks can be used against the project. In fact, I believe any project, even ones that don’t use databases are vulnerable to a hacking like this. Nobody is hacking CreatiCode right now, but I bet if someone smarter than me decided they wanted to, they wouldn’t have a very hard time because of the security vulnerabilities and over-trusting the client. In computers they said “never trust the client”, which is why you shouldnt just hide private things from the client, but also make sure that the private things are inaccessible if someone decides to edit or abuse their client (done with “Inspect Element” for websites).
@jeffreyrb03-gmail Ah i get it. Why not just delete the data if the user tries to log in from a different location then what they normally do, then tell them not to log in from a different country so they don’t lose all of their hard earned points?
-
@jeffreyrb03-gmail Ah i get it. Why not just delete the data if the user tries to log in from a different location then what they normally do, then tell them not to log in from a different country so they don’t lose all of their hard earned points?
@jamesa-blackwell-57b383d3 You don’t get it, but I’m not sure how else to explain it. All I’m saying is, don’t store super sensitive or private stuff in the Database blocks of CreatiCode. If you’d like, you can create a project that uses a database, store some secret in it, then ask me to hack it (for educational purposes, as I do not wanna mess up random projects)
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login