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.
Related
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'm using mysql workbench as my db client. I have two databases one is giving data mydb_1 and another is receiving the data called mydb_2.
So, below are my doubts :
How can be the data transformation is happening between these DB's?I have checked whether any stored procedure call or triggers have been written but i was unable to find out that because stored_procedures are not visible to my credentials?
I suspect may be i don't have required privilege's, if i don't have proper privilege, so even i wouldn't see the stored procedures? is it dint?
Is there any alternative way to find, how mydb_2 is getting updated?
Because of the access restriction, I was unable to see the stored procedure code.
So, I enabled the MySQL binary log to find, how the data transformation is happening between two databases for the restricted user. Even though
this didn't give entire information but partially I have found some information which can sort my problem.
I am attempting to recover statements within procedures in a MySQL database. It seems that when using cPanel through GoDaddy, the user changes when logging in through PHPMyAdmin, resulting in the 'definer' of a procedure being different than the current user after a single logout. This seems to prevent SHOW CREATE PROCEDURE from returning a proper CREATE statement due to permissions.
A workaround is perhaps defining a user and using the account in defining procedures. While not desirable, it may be sufficient.
Is there any way to recover the existing procedures?
A backup of the database may be performed through cPanel, which includes the procedures.
When we migrate from SQL Server to mysql only table structure and data transfer, stored procedures, views and triggers don't transfer. Is there any why to transfer stored procedures and triggers using mysql migration help or any other tool? I'll be very thankful to help me. Why stored procedures and views do not transfer while I select both check boxes in ysql Workbench?:
The problem is that transferring database objects that contain code is not really straightforward and myqsl workbench does not transfer them automatically. See mysql workbench documentation on Migrating from supported databases:
Generally speaking, only table information and its data are automatically converted to MySQL. Code objects such as views, stored procedures, and triggers, are not. But supported RDBMS products will be retrieved and displayed in the wizard. You can then manually convert them, or save them for converting at a later time.
I agree, this should be made more clear in the user interface of mysql workbench. There are other migration tools that claim to be able to automatically migrate such objects between ms sql and mysql (recommending tools is out of scope, but with some google serach you will find them), but I have yet to see an application that can truly migrate complex code from one rdbms to another.
I've exported a database via SSH and I didn't add --routine command to export the routines.
Now I don't have any access to this database, and I have only one .sql file. is there any way to restore and find the routines through PHP code or database structures?
No, sorry, in this case I think you're out of luck. Looking at the database structure, you won't be able to figure out what a routine might have done. Likewise, looking at the PHP code is probably not going to help. If you know what the routines did (for instance, manipulate data on insert, maintenance by deleting some rows, or some such) you can work through recreating it, but that's basically reverse engineering it based on what breaks when you try to run your application.