How to include a .sh (script) file in Mysql stored procedure? - mysql

Is it possible to include a Script file (.sh file) inside a stored procedure in Mysql?
If yes, then how?
And if no, then why?

Like #mu is too short said:
You need to install these UDF's from: http://www.mysqludf.org/lib_mysqludf_sys/index.php
Here's the download link: http://www.mysqludf.org/lib_mysqludf_sys/lib_mysqludf_sys_0.0.3.tar.gz
Note that you shell commands will run with the privileges of the MySQL user, not with the privileges of the user that's connecting to MySQL.
For a security point of view this is probably a bad idea.
Note the warning in the link:
A Note of Caution
Be very careful in deciding whether you need this function. UDFs are available to all database users - you cannot grant EXECUTE privileges for them. As the commandstring passed to sys_exec can do pretty much everything, exposing the function poses a very real security hazard.
Even for a benign user, it is possible to accidentally do a lot of damage with it. The call will be executed with the privileges of the os user that runs MySQL, so it is entirely feasible to delete MySQL's data directory, or worse.
The function is intended for specialized MySQL applications where one needs extended control over the operating system. Currently, we do not have UDF's for ftp, email and http, and this function can be used to implement such functionality in case it is really necessary (datawarehouse staging areas could be a case in example).
You have been warned! If you don't see the hazard, please don't try to find it; just trust me on this.
If you do decide to use this library in a production environment, make sure that only specific commands can be run and file access is limited by using AppArmor.

Related

Restricting commands to procedure only in MySQL / MariaDB

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.

Login to mysql programmatically

I'm writing a c program and need to login to a mysql database. I'm trying to find a simple yet secure way of storing the username and password in the program. The program will make https calls to the mysql server. I just need to be able to include the user/password data and I don't want to store it as a string in the program.
Anyone know a simple yet secure way to do this?
This is on a linux system. raspberry pi debian (jessie).
You should not hardcode username/password into your binary, since it is very unflexible and you will tend to not change this password regularly if you have to recompile the binary each time. Furthermore, binaries are usually not specially read protected, so other users might get your password.
Passing the credentials as program arguments is a bad idea, too, since it might show up in a process list, may be safed in command line histories, may be logged by auditing tools etc. pp., so your password might end up in several places you don't want it to show up.
Your best option is to employ a configuration file with the credentials and give it the minimal rights it needs, so your credentials are safe. A simple library for linux is for example libini, which allows you to store key/value pairs in sections, but there are many other options.
Another quite safe option, which is for example employed by apache for private key passphrases and similar, is to specify a program (usually a shell script), which is executed and outputs the credentials on stdout, which is then parsed by your program. Again, you have to make sure here, that only authorized users/processes may read or execute that script.

If an attacker were able to read a Joomla!'s database, would he be able to do much harm?

I found out after a while that a component used on my website had an unfiltered parameter, in a WHERE condition in the following settings:
Using Joomla! 1.5, latest update.
The component is custom made, fairly small, and after reading its source I couldn't indentify any other security flaws.
The attacker was using SQLMap to do their work, as I saw its user-agent in the log.
MySQL version is 5.1.11
PHP version is 5.1.4
The database user has USAGE privilege.
The server OS is Linux.
After trying the same steps on my own box, I was able to read the database (and since I'm not an expert in sql injection I'm not sure that was all I could do).
My worry is mostly about the session table, would the attacker be able to impersonate a user from it? Aside from that, is there any chance he could have uploaded some payload to my server?
Also, could he have "magically" updated some field through this SELECT query? (No stacked queries available).
Thanks in advance.
If you can read the database, you can dump it with SQLMap and find the hash of the administrator's password.
With that hash, the attacker could crack it (or if it is MD5, find a collision fairly quickly) and login into your administrator account.
From there, your admin account is screwed. The attacker has admin privileges, so consider your site dead. Worse than that, if Joomla is like Wordpress, the attacker can use a custom PHP code in the theme, which allows them to drop to OS level and modify your Joomla installation.
In short, they can screw up your server, as Joomla executes arbitrary PHP code when it is run.

How to restrict user from modifying data in mysql data base?

We need to deploy application(developed by Java) WAR file in client place which make use of MySql 5.0. But we would like to restrict the client (the application owner, not the webpage visitor) from modifying any data in the database. Is there any way to protect data. The client can make use of the application but they should not be able to change any value in database. How to do that?
Manage Role/User permissions
Create an sql user (you should already have one), which will have only SELECT permission. So it would be something like
GRANT SELECT ON db_base.* TO db_user#'localhost' IDENTIFIED BY 'db_passwd';
http://kb.mediatemple.net/questions/788/HOWTO:+GRANT+privileges+in+MySQL
http://blog.wl0.org/2010/01/managing-mysql-grants/
http://www.ntchosting.com/mysql/grant.html
Check links below for further reading
FOR MySQL
Best Practice for Designing User Roles and Permission System?
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.devshed.com/c/a/MySQL/MySQL-User-Account-Management/
Can't set permissions on MySQL user
http://www.aquafold.com/d7/docs/BD5C99E4-3B55-C812-8318-6338A9A89ED9.html
FOR SQL Server.
http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm
http://www.mssqlcity.com/Articles/Adm/SQL70Roles.htm
http://www.sql-server-performance.com/articles/dba/object_permission_scripts_p1.aspx
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html
http://www.databasejournal.com/features/mssql/article.php/2246271/Managing-Users-Permissions-on-SQL-Server.htm
This is impossible; if you deploy the application at the client, he will have the credentials and will be able to log into the MySQL database and pretent he is the application. And thus he can make any change to the database that your application can.
The only way to solve this securely is to make a tier between the client and your MySQL database, and make sure that you control this so that it is only possible to make 'legal' changes.
Just write the code accordingly so that the user doesn't have any chance to modify the database? I.e. the code doesn't execute any INSERT or UPDATE and/or controls the access based on a login/role.
I honestly really don't forsee any problems here, or the code must be prone to SQL injection attacks.
Update: The above answer is actually irrelevant since the question is clarified. Turning into Community Wiki.

Secure(r) storage of MySQL login information?

First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.