Although any database can eventually be penetrated, you can counter it.
For example, I have to use replit Database instead of db so that databases are synced properly. However, when you define your REPLIT_DB_URL (you can find yours by typing in the console: echo $REPLIT_DB_URL) some people forget to not show people their database key.
Old method: Hide the variable inside of .env
New method: Secrets tab.
“Secrets” allow you to define variables that are not present in your program.
db = Database("https://kv.replit.com/v0/eyJhbGciOiJIUzUxMiIsImlzcyI6ImNvbm1hbiIsImtpZCI6InByb2Q6MSIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJjb25tYW4iLCJleHAiOjE2ODEwNTAzMDcsImlhdCI6MTY4MDkzODcwNywiZGF0YWJhc2VfaWQiOiJmYWQ3ODhhZi1lNDEzLTQ1NzEtOTdlZS1jOTZkOTZjYjdhZmIiLCJ1c2VyIjoiLWpwZyIsInNsdWciOiJkYi1leGFtcGxlIn0._RJdFyTS9qA7By3aCYKRbSiMriO9N5htPl3GBwc8kXnbNkmbYJxVe3UeKf93p4KKjlOTzFguVMomrBQJ8NzUEQ")
to:
db = Database(db_key) # db_key defined in secrets
or:
from os import environ
db = Database(environ["REPL_DB_URL"])
However, you are not safe quite yet.
If you are building yourself an “OS” in replit and you plan to give them console access, either:
dont use replit database for storing important information
block access to that command
To do method two, follow this code example:
Python:
from os import system
while True: # or however you plan to do this
user = input(">> ")
if not user == "echo $REPLIT_DB_URL":
system(user)
else:
print("Access denied.")
Method one is less straight-forward, you will have to configure an external database of some sort.
Of course; different methods of getting into your database exist but this prevents common types of attacks. Try it out yourself: https://replit.com/@-jpg/db-example
This… Doesn’t go in #general:showcase. I get you’re proud, but it is not showing off any Repl or Theme. So please let me move it to #general with the #resource tag. Thanks.
there’s really no way to protect it unless replit does more encrypting for us because environ doesn’t update (don’t have time to explain but it doesn’t)
Yes, I did not claim this could stop anyone. That was just so you could see an example of how to do such. You cut off my entire comment, db_key is defined.
Yes, indeed this does not stop all types of attacks; but just people who are inexperienced cannot get into your DB easily. Including that and what @dragonhunter1 said, you can further add restricted commands; or outright just detect if the output from a command is/has your replit db key.
No matter what you do, if you give them a shell, they can get your replit db key. Even if they have to launch a subprocess that kills your webserver and starts code-server without authentication, if they can execute a command, they will get it eventually.