I've put together a FiveM server using alot of public code and discovered there are cheat systems out there that allow the user to corrupt or delete the underlying database. The reason is because they can inject Lua scripts which can contain DROP, DELETE INSERT and UPDATE and if they know the schema potentially could do whatever they like.
My intention is to deny access to every command except for SELECT and move all the other logic to stored procedures. The thing is that the user executing the proc will be the game user account which if locked out would also be blocked server side? Am I able to deny access from calling applications but allow access from within a stored procedure or have the procs execute as a different account vs the normal SELECT statements? Are there any other considerations or designs that could work? I'll be using parameters across all calls to help guard against injection, but I'm fairly new to MySQL so wondering what other steps people take for these scenarios.
Yes, you can give the MySQL user privilege to call procedures only. Then the procedures execute with the privileges of the user who defined the procedure.
Read https://dev.mysql.com/doc/refman/8.0/en/create-procedure.html the parts about SQL SECURITY which has choices DEFINER or INVOKER. The default is DEFINER, which is what you want.
However, you would also need to deny SELECT privilege to the app user. A malicious user can cause problems with nothing but SELECT privilege. They can't change data, but they can overload the database server.
So you'd need to implement every database query, both reads and writes, in a collection of stored procedures.
Here's an alternative suggestion: Allow the app to work as it does today, where the app connects using its username and does SQL queries directly.
But if the user wants to invoke their Lua script, only allow that on a separate database connection, using a different MySQL user with limited privileges. Basically only the EXECUTE privilege on a specific schema. You can implement a set of stored procedures that the Lua script is allowed to run, and put them in that schema. Then Lua scripts cannot do other tasks that the app does, a Lua script can only run the finite set of procedures you want to allow them to run.
I am practising creating MySQL stored routines and am having problems editing them from different areas. If I create it in HeidiSQL, the definer is saved with the IP address so can only edit them in HeidiSQL from the same IP. If I create them in phpMyAdmin, it is only editable from phyMyAdmin, not HeidiSQL.
When you bear in mind that I can edit the actual table data (create, delete, drop, etc) from anywhere (if I have added the IP address), it seems ludicrous that these limitations occur with what is essentially a simple function.
Is there any way, when creating a stored routine, I can set the definer so that it is accessible from whatever program and IP address I am using?
You need to grant alter routine privilege to your users on either database or global level using the grant statement. This way they can edit each other's stored procs. Both heidisql and phpmyadmin provide GUIs for changing privileges.
Apparently, you did not properly set up the users' privileges, so no reason to blame mysql.
Currently I am using MYSQL 5.6 database.
I have so many store procedures and functions in one database say database "AppDatabase" for my application which I am developing right now.
What I want to gain is :
Only my program should have all rights for "AppDatabase". I want to prevent any database user to view my store procedures and functions. Even database administrator should not be able to view any store procedure and any function.
I want to secret my database store procedure and function code.
Is it possible to achieve in mysql?
You can check out the Access Control for Stored Programs and Views
Suppose you're writing a simple database web application using Ruby and MySQL. Access to the database is controlled by Ruby code. The user name that the Ruby code uses to access the data is the only regular user on the database. Does it make sense for that user to be "root"? Or is there any extra security in creating a second user just for the application?
Simple, consider the root as the main user, who can do everything (by default).
If he wants to dump the whole database, he can, if he wants to create some data to create (for example) fake account to overpass your bank system, he can.
So if your code is not enough secure (and this is quite often usually), you have strong security issue.
Usually, "a basic" security (really basic), should looks like that :
create a simple user, give him (with GRANTS) the right to SELECT, INSERT, UPDATE and DELETE on a specific database.
create another user who can SELECT and lock tables and SHOW VIEWS to perform dump (database save).
On a more "complex" system, you should create many users, depending of what they should access, this is for simple reason : if somebody got a SQL injection access, if the user can only access to a single view (for example), and not the whole database, this is a security issue but not the baddest one...
Also view are often used for that...
And finally don't forget triggers if you want (for example a log table), to disable insert or update or delete on a table, for everybody (except somebody who can destroy trigger of course) :
Use a trigger to stop an insert or update
Besides editing or deleting all data in your database, the root user also have the FILE privilege which gives access to:
LOAD DATA INFILE which can be used to read any file on the server machine.
LOAD DATA LOCAL INFILE which can read files on the client machine (the web server machine).
SELECT ... INTO OUTFILE which can create files on the server machine.
This is why your application should have only the privileges it needs, and this is also the reason your MySQL server daemon should be run as a non-privileged user on the server machine.
See also General Security Issues in the manual.
If everybody/thing is root, you lose auditability, you lose the ability to restrict the app to stop attacks (i.e. your app doesn't need this segment of sensitive information, seal it away from its user). If somebody compromises the app, you can suspend the account etc.
I would not make a user "root".
I'd create a separate username and password just for that application and GRANT it only the permissions required to do its job.
I would create a new user, giving it only the permissions it needs (SELECT, UPDATE, INSERT and DELETE usually do the trick). Like that, you limit the ability for the code to be manipulated in an unintended way.
"root", or generally speaking, users with Super User privileges, can change passwords, delete accounts, and therefore prevent you from accessing your own database.
If you server hosts only one application, then you may not need to create several lesser privileged accounts. However, it is common practice to create at least one user for each application, so that if one application gets compromised, other applications (and underlying data) may not be.
I am looking into ways to encrypt mySQL stored procedure source code when installed in clients local environment.
I did lot of research on this topic and had no luck except for one promising reply from gazzang.com
Here is the reply from gazzang. Let me know if someone has already tried this out.
We should be able to encrypt the table where store procs and functions are stored - mysql.proc
Thus os users won't be able to read the contents of the sp or functions.
I can't remember which internal table views are stored in but the same some apply to them.
I am not sure we could come up with a solution to encrypt the routines internal to mysql.
Other databases that do this really implement "obfuscation" internally - I think PostgreSQL does that for example.
You cannot encrypt stored procedures in a really useful way, because MySQL server will have to decrypt it anyway when it reads stored procedure from it's tables. If you encrypt the table file, your customer will login as root and make dump on mysql.proc table using native MySQL statements. If you change root password, they will always have a way to start MySQL with --skip-grant-tables switch to overcome that.